>From: "David Geary" <[EMAIL PROTECTED]>
>
> 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
> >
