shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Geary" <sabrew...@gmail.com>
Subject Re: [dialog] Missing requirements?
Date Tue, 29 Aug 2006 17:37:39 GMT
It might be worthwhile to sufficiently generalize this so that it can be
used by applications that have their own config files.


david

2006/8/28, Gary VanMatre <gvanmatre@comcast.net>:
>
> >From: "Craig McClanahan" <craigmcc@apache.org>
> >
> > 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