shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gvanma...@comcast.net (Gary VanMatre)
Subject Re: [dialog] Missing requirements?
Date Tue, 29 Aug 2006 18:27:52 GMT
>From: "David Geary" <sabreware@gmail.com> 
>
> It might be worthwhile to sufficiently generalize this so that it can be 
> used by applications that have their own config files. 
>

Yea, even if it was not used by something other than Clay, it would clean up that monster
ComponentConfigBean class :-)

 
> 
> david 
> 

Gary

> 2006/8/28, Gary VanMatre : 
> > 
> > >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. 
> > #{ 
> > > dialog.data.foo}), 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 WatchDog. 
> > 
> > 
> > 
> http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/java/org/ 
> apache/shale/clay/config/beans/ComponentConfigBean.java?view=markup 
> > 
> > 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. 
> > 
> > 
> > 
> http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/java/org/ 
> apache/shale/clay/config/beans/ConfigBean.java?view=markup 
> > 
> > It uses a preprocess filter command as the timer so there are not any 
> > threads not controlled by the container. 
> > 
> > 
> > 
> http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/java/org/ 
> apache/shale/clay/config/beans/ConfigDefinitionsWatchdogFilter.java?view=markup 
> > 
> > 
> > 
> > > Paul Spencer 
> > > 
> > > 
> > > Craig 
> > 
> > Gary 
> > 
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message