Quoting Joe Germuska <[EMAIL PROTECTED]>: > At 5:24 PM -0800 3/21/04, Craig R. McClanahan wrote: > >I think the presentation-tier-independent things about Tiles (like mapping > >forwards to definitions) should be built in to the core, so there isn't any > >such thing as a separate TilesRequestProcessor (or a separate chain or > >whatever). In turn, this probably means we might need an API abstraction > that > >alternative presentation tier technologies can use to integrate > >themselves into > >the underlying support. > > I managed to make Tiles work with struts-chain with a single > pre-processor Command. It basically looks up a tiles definition and > replaces the ForwardConfig returned from an action with its own that > has a path which RequestDispatcher to which can forward. > > But it still uses the TilesPlugIn... is that part of what you think > should be moved up into the core? Or do you think even the single > Command is not the best future implementation?
I'll express my goals for this from a couple of perspectives: >From the user's perspective, the fact that I'm using Tiles (or not) should not require anything extra in the config (other than adding the definitions of the tiles themselves, of course). This probably implies that the configuration data migrates into struts-config.xml as well. >From the Struts developer perspective, I don't want to have to maintain two request processors (or really even two command chains) -- the standard chain should handle requests whether or not you reference a Tile. So, if your command that looks up the Tiles definition works on non-Tiles requests as well, we can just build it in to the standard chain and call it good. > Joe Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
