shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Gary VanMatre)
Subject Re: [dialog] Missing requirements?
Date Tue, 29 Aug 2006 02:47:23 GMT
>From: "Craig McClanahan" <> 
> On 8/28/06, Paul Spencer wrote: 
> > 
> > Should the following be added as a requirements: 
> > 
> > o A managed bean can be populated by one or more action and views solely 
> > via 
> > configuration. The use of the dialog API by the user's application is 
> > not needed. 
> > Said another way, an existing JSF Bean and view, view.jsp, can be 
> > broken up into 
> > a dialog by configuring the dialog and breaking apart view.jsp into 
> > many 
> > jsp files. 
> > (Currently this is possible when using session managed beans.) 
> I'm not quite sure how to articulate this as a requirement. Woutd it be 
> sufficient to say "You should be able to utilize the dialog functionality 
> WITHOUT being required to use the provided state storage mechanism (i.e. #{ 
>}), as long as the application manages this state itself" or 
> something like that?. If so, I think that might be a reasonable requirement 
> to add -- although in practice I'm having a hard time figuring out how a 
> dialog framework could make this NOT work. 
> o Changes to the dialog configuration will not require a restart of the 
> > application 
> > in order to take affect. (Currently the servlet engine must be 
> > restarted or the 
> > web application must be reloaded for changes to dialog-config.xml to 
> > take affect.) 
> Makes sense ... and it should apply to any and all configuration files, not 
> just the dialog one. I think Clay has a mechanism for this already that we 
> should be able to reuse. 

Clay's file reload mechanism is wired into the ComponentConfigBean as an inner class called

A group or single file is defined by a logical name.  If one of the files in the group is
dirty, the entire group is reloaded.  You can also force a reload.  This is necessary if one
group has a dependency with another group.  For example, in Clay, if a common config file
is changed, all files need to be reloaded since definitions in one file can extend definitions
in the commons config files. We might be able to abstract out with a couple hooks you need
to implement or register a callback adapter.  Commons chains might also work here.

The files are define using a top level interface.  It could also be pulled out.

It uses a preprocess filter command as the timer so there are not any threads not controlled
by the container.

> Paul Spencer 
> Craig 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message