> 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. Then, a Filter could be used for tiles outside of Shale. Gary > 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]
