I've kept an eye on this thread as stxx uses a similar integration strategy as Tiles. I considered using the Velocity approach, but decided it wasn't ideal as it exposed paths to client that didn't need to be exposed. I like the strategy of hiding alternate view processing within Struts as, again, it keeps those special urls hidden and secure. I use this approach for both Tiles and the Cocoon plugin.
Don On Thu, 24 Mar 2005 12:50:05 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > At 9:12 AM -0700 3/24/05, David Geary wrote: > > > >>David G, or anyone: is there a reason that the TilesServlet class > >>was removed from the distribution? > > > >It was removed because Tiles had become so intertwined with Struts > >that the Struts developers did not want to support two Tile > >versions: one for use with Struts and another without. > > Whoops; forgot we've got two David G's now -- it was David Graham who > removed the other file, but given your interest in Tiles, obviously > you're a good candidate for an answer. > > >Having said that, decoupling Tiles from Struts won't solve the > >problem that Martin brings up. That's an integration issue that's > >arisen due to the composable request processor. Integration with > >Tiles requires Struts to be Tiles-aware. Whether Struts is > >intertwined with Tiles is another issue. > > Ah, now I'm understanding more. The TilesServlet really just > initialized Tiles; I was thinking it serviced requests, and that you > could forward request processing to it equivalently to how you > forward request processing to a JSP. > > So the critical service which the TilesPreProcessor performs which > the TilesServlet doesn't is extracting a JSP path from the base tiles > definition and setting things in motion so that control is forwarded > there. > > It still seems totally possible to write a smarter TilesServlet which > might be mapped, for example, to serve > <url-pattern>*.tiles</url-pattern>, and then it would have a simple > process which derived the name of a tiles definition from the request > URL in much the same way that Struts looks up ActionMappings. > > If this were the case, then there would be no need for a > TilesPreProcessor command, let alone for putting it in two locations > in the chain. It wouldn't be backwards compatible, since most people > probably don't use tiles names which would also be valid paths to > which a request dispatcher could forward -- but we could deprecate > the TilesPreProcessor once a smarter TilesServlet existed. > > Isn't this essentially how people use Velocity for their view > technology in Struts? From a cursory look-through, I don't see > anything very critical to Struts done in this command. > > Joe > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > > --------------------------------------------------------------------- > 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]
