incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Gary VanMatre)
Subject Re: Shale and dialog framework
Date Tue, 30 Jan 2007 00:09:38 GMT
>From: "Craig McClanahan" <> 
> On 1/29/07, Meyer, Stefan wrote: 
> > 
> > The Viewcontroller does not work well with the dialog framework, because 
> > the lifecycle methods are called on the popup view bean for the parent 
> > and child request and not at all for the launching view. Fixing this 
> > would maybe mean, that the action outcome cannot define the view to 
> > present in the popup. 
> > 
> Stefan, 
> I am not sure I quite get what you mean here. 
> My assumption, when you are using a popup, is that you'll be using client 
> side JavaScript to actually create the popup. Here's a snippet of code from 
> our "shale-test-dialog-basic" and "shale-test-dialog-scxml" test 
> applications that does it: 

I was looking at the Trinidad's Dialog the other day. The Trinidad dialog also uses Javascript
to launch a new browser window [1] but the hook is seamless if you are using their widgets
(Trinidad) which have their own rendering strategy [2]. This is a huge advantage that a full
component library might offer since they offer components that encapsulate this functionality.

Another example might be to compare Shale's commons validator's client side script support
versus Trinidad's. In Trinidad, each server side validator has a corresponding client javascript
validator. The same is true for converters. Shale's client side validator support is patterned
from Struts. The client side validation scirpt is rendered from a component that you add to
the bottom of the page that inspects all the validators and adds the script. 

I like Trinidad's approach. Each JSF "component" (widget, validator, converter, listener)
should act on it's own behalf. But, the problem is that only components participate in rendering
markup. Trinidad's approach is very elegant but cohesive.  

Shale's approach as been less component library centric and more API centric. Maybe what we
need is for the JSF API to standardize on a script delivery channel, dialog mechanism, and
a pluggable rendering extensions for validators and converters?



> Note that this does *not* send back a request for the calling view (the page 
> in which the JavaScript above was embedded), so there is no reason to invoke 
> any callback methods for it. This request will open a new window, and the 
> callbacks for the "menu.faces" page will be called as expected. 
> What part of this behavior is not working for you? 
> Craig 
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message