Le 05-07-28 à 16:14, Greg Reddin a écrit :
[EMAIL PROTECTED] wrote:
On Jul 28, 2005, at 4:45 PM, [EMAIL PROTECTED] wrote:
The JSP-like approach would be more intrusive. The
DefinitionsFactory
would have to store the modified date of a definition and the
getDefinition() method would have to check the date against the
date of
the file and reload if necessary.
Maybe a Shale preprocess command would be a good fit?
<!-- Define preprocessing command chain for Shale to execute -->
<catalog name="shale">
<!-- Disallow direct access to JSP and JSFP resources -->
<chain name="preprocess">
<command
className="org.apache.shale.application.ContextRelativePathFilter"
includes="\S*\.faces,\S*\.html,\S*\.gif,\S*
\.jpg,/index\.jsp"
excludes="\S*\.jsp,\S*\.jspf"/>
<!-- listen for tiles config file changes -->
<command
className="org.apache.shale.application.TilesReloadFilter"
includes="\S*\.faces,\S*\.html,\S*\.jsp"/>
<!-- listen for clay config file changes -->
<command
className="org.apache.shale.clay.application.ClayReloadFilter"
includes="\S*\.faces,\S*\.html,\S*\.jsp"/>
</chain>
</catalog>
That's pretty cool. The only downside (if it is a downside) is
that it makes the reloadable feature part of Shale and not part
of Tiles. Though it could probably be included in Tiles
standalone if we wanted to.
True. I suppose that if both the tiles DefinitionsFactory and the
clay ConfigBeanFactory could provide their own implementations
with a checkReload method that's fired from a preprocess command?
I think that was your original suggestion.
Yep, that's a much better approach than instrumenting the
DefinitionsFactory itself. I'll see if I can find some time to
play with this.
I'm not sure I like pulling Chain into Tiles standalone (we are
talking about writing a Chain Command in Tiles, right?). I would
prefer a POJO in Tiles that does the dirty work (Shale could have a
Command wrapper that calls Tiles' POJO, if need be). A Chain Command
smells of Shale and I would prefer not to have that smell, even if
it's a good smell, in standalone Tiles.
Another thing is that Shale already has a Tiles view handler that we
might be able to use to call the Tiles POJO (or Command, if someone
has a good reason). Then Shale users would get it for free w/o having
to bother with yet another configuration detail. The difference, of
course, is that the view handler is called at the end of the JSF
lifecycle, whereas the command would be called at the beginning. I'm
not sure if that has ramifications.
Finally, it seems to me that this is the easy part. The challenge
will by synchronizing Tiles so that it doesn't trip up when
something's changed from underneath it.
david
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
