Le Mar 24, 2005, à 4:34 AM, Joe Germuska a écrit :
At 8:38 PM -0800 3/23/05, Martin Cooper wrote:In the regular scheme of things, when, for example, an Action returns an ActionForward, the request processor lets Tiles have a look at the forward, so that it can handle the case where a path is a Tile rather than a genuine path. Unfortunately, this doesn't happen in all cases, specifically in the new world of Chain and the composable request processor.
For example, when the path in an <exception> definition is followed, Tiles doesn't get a chance to play in the game. This is because Tiles only gets to play after ExecuteAction succeeds. In this particular case, I believe that inserting the TilesPreProcessor command in the middle of the 'servlet-exception' chain will do the trick.
However, before making this change (and testing it ;), I wanted to ping the list to see if there are other scenarios that people can come up with in which this kind of thing might happen. Is this just a one-off bug, or do we have a bigger issue with getting Tiles into play in all the right places?
Well, I think it's kind of a hack -- albeit I think it's the right hack based on what we have right now. Putting the PreProcessor in there should make it work, at least.
Reasons like this are what make me pretty sure that the best possible scenario would be to push all of Tiles into its own TilesViewServlet which would simply be mapped to some other Servlet handling path, and leave the tiles processing to requestDispatcher and the servlet container.
I know that this is how non-Struts projects use Tiles.
I just haven't looked at what exactly is gained by using Tiles inside Struts instead of outside of it -- when I made the TilesPreProcessor, I just tried to replicate the behavior that the TilesRequestProcessor added. But given that people do use it outside of Struts (i.e. http://www.jroller.com/page/RickHigh/20040609#tiles_and_jsf_oh_my), it's probably doesn't do anything more than save the trouble of configuring a second servlet.
You also get the integration that Martin describes in the first para above.
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.
I've got a standalone version of Tiles, which I'd like to use as the starting point for the top-level Tiles project. Awhile back, Ted suggested that I retrofit Struts with that version. I just got my ASF committer account reactivated, so it's time for me to give this some attention.
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.
david
http://cvs.apache.org/viewcvs.cgi/jakarta-struts/src/share/org/apache/ struts/tiles/TilesServlet.java?hideattic=0&rev=1.6&view=log
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]
