You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Martin Cooper <mf...@gmail.com> on 2005/03/24 05:38:01 UTC
Getting Tiles and Chain to play nice together
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?
--
Martin Cooper
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Getting Tiles and Chain to play nice together
Posted by Don Brown <mr...@twdata.org>.
To borrow a JSF term, what about ViewHandler? :)
Don
Martin Cooper wrote:
<snip />
> OK, I hadn't thought about taking it that far. ;-) So this thingumajig
> would effectively do what PerformForward and PerformInclude do now (or
> what used to be doForward() and doInclude() in the old request
> processor), right? And the Tiles version would do more or less what
> TilesPreProcessor does now?
>
> I think that could be pretty cool, and unless I'm mistaken, it would
> mean that plugging Tiles into Struts would require only (a) loading
> the Tiles defs, and (b) registering a thiingumajig, both of which
> would happen at startup time, and neither of which would involve
> modifying the request processor. Maybe I'm missing something, but that
> seems much cleaner than what we have now.
>
> We'd need to figure out what kind of registration mechanism we want.
> My first thought was to have Tiles call a registerThingumajig()
> method, but I think we'd want to allow for control over the order in
> which thingumajigs get a chance to play in the game. This seems like a
> natural for Chain (give each thingumajig in the chain a chance to play
> until one says "I got it"), but maybe I've got chain on the brain...
>
> I've been calling this new thing a "thingumajig" here because I don't
> think "path resolver" or "path handler" (or "path ${foo}") really
> captures what it does. It's kinda like "OK, take it from here" as far
> as Struts goes. I don't have any great ideas on what to call that
> right now.
>
> --
> Martin Cooper
>
>
>
>>Don
>>
>>
>>>--
>>>Martin Cooper
>>>
>>>
>>>
>>>
>>>>If you put your .tiles paths all under /WEB-INF/ then wouldn't you
>>>>achieve the same kind of protection that people who put JSPs there
>>>>do? It seems like that should work, although that's pure
>>>>speculation.
>>>>
>>>>Joe
>>>>
>>>>--
>>>>Joe Germuska
>>>>Joe@Germuska.com
>>>>http://blog.germuska.com
>>>>"Narrow minds are weapons made for mass destruction" -The Ex
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Getting Tiles and Chain to play nice together
Posted by Martin Cooper <mf...@gmail.com>.
On Thu, 24 Mar 2005 16:07:24 -0800, Don Brown <mr...@twdata.org> wrote:
> Martin Cooper wrote:
> > On Thu, 24 Mar 2005 17:37:05 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> >
> >>At 1:23 PM -0800 3/24/05, Don Brown wrote:
> >>
> >>>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.
> >>
> >>I see your point, but I still think needing to explicitly configure
> >>the TilesPreProcessor for two different view contexts is a hack. It
> >>has the bad-code smell that makes me think that we need to
> >>re-engineer something -- even if I don't know what.
> >
> >
> > Perhaps what we need is the concept of a "path resolver" that takes a
> > virtual path and turns it into a real path. The default would be
> > passthrough, but it would be pluggable in some way so that Tiles (or
> > stxx or whatever) could register with it and be given a chance to
> > resolve, for example, a tile name to a real path. Then we just make
> > sure that anywhere we're about to do a forward (or an include), we
> > invoke the path resolver first.
> >
> > Does that make any sense?
>
> I like where this is going...I would rather call it a "path handler".
> The role of this path handler would be to completely process the path,
> most likely returning output back to the user. The default handler
> could do a dispatch like it does now, but anyone could create their own,
> say, a PDF handler. I kinda have this built into stxx to allow
> completely control, in our case, of how the XML is used to generate
> output. I have used a PDF handler, XSLT, Velocity, SVG, and Cocoon at
> different times. Basically this "path handler" would to the view that
> the Action is to the controller, but more generic.
OK, I hadn't thought about taking it that far. ;-) So this thingumajig
would effectively do what PerformForward and PerformInclude do now (or
what used to be doForward() and doInclude() in the old request
processor), right? And the Tiles version would do more or less what
TilesPreProcessor does now?
I think that could be pretty cool, and unless I'm mistaken, it would
mean that plugging Tiles into Struts would require only (a) loading
the Tiles defs, and (b) registering a thiingumajig, both of which
would happen at startup time, and neither of which would involve
modifying the request processor. Maybe I'm missing something, but that
seems much cleaner than what we have now.
We'd need to figure out what kind of registration mechanism we want.
My first thought was to have Tiles call a registerThingumajig()
method, but I think we'd want to allow for control over the order in
which thingumajigs get a chance to play in the game. This seems like a
natural for Chain (give each thingumajig in the chain a chance to play
until one says "I got it"), but maybe I've got chain on the brain...
I've been calling this new thing a "thingumajig" here because I don't
think "path resolver" or "path handler" (or "path ${foo}") really
captures what it does. It's kinda like "OK, take it from here" as far
as Struts goes. I don't have any great ideas on what to call that
right now.
--
Martin Cooper
> Don
>
> >
> > --
> > Martin Cooper
> >
> >
> >
> >>If you put your .tiles paths all under /WEB-INF/ then wouldn't you
> >>achieve the same kind of protection that people who put JSPs there
> >>do? It seems like that should work, although that's pure
> >>speculation.
> >>
> >>Joe
> >>
> >>--
> >>Joe Germuska
> >>Joe@Germuska.com
> >>http://blog.germuska.com
> >>"Narrow minds are weapons made for mass destruction" -The Ex
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Getting Tiles and Chain to play nice together
Posted by Don Brown <mr...@twdata.org>.
Martin Cooper wrote:
> On Thu, 24 Mar 2005 17:37:05 -0600, Joe Germuska <Jo...@germuska.com> wrote:
>
>>At 1:23 PM -0800 3/24/05, Don Brown wrote:
>>
>>>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.
>>
>>I see your point, but I still think needing to explicitly configure
>>the TilesPreProcessor for two different view contexts is a hack. It
>>has the bad-code smell that makes me think that we need to
>>re-engineer something -- even if I don't know what.
>
>
> Perhaps what we need is the concept of a "path resolver" that takes a
> virtual path and turns it into a real path. The default would be
> passthrough, but it would be pluggable in some way so that Tiles (or
> stxx or whatever) could register with it and be given a chance to
> resolve, for example, a tile name to a real path. Then we just make
> sure that anywhere we're about to do a forward (or an include), we
> invoke the path resolver first.
>
> Does that make any sense?
I like where this is going...I would rather call it a "path handler".
The role of this path handler would be to completely process the path,
most likely returning output back to the user. The default handler
could do a dispatch like it does now, but anyone could create their own,
say, a PDF handler. I kinda have this built into stxx to allow
completely control, in our case, of how the XML is used to generate
output. I have used a PDF handler, XSLT, Velocity, SVG, and Cocoon at
different times. Basically this "path handler" would to the view that
the Action is to the controller, but more generic.
Don
>
> --
> Martin Cooper
>
>
>
>>If you put your .tiles paths all under /WEB-INF/ then wouldn't you
>>achieve the same kind of protection that people who put JSPs there
>>do? It seems like that should work, although that's pure
>>speculation.
>>
>>Joe
>>
>>--
>>Joe Germuska
>>Joe@Germuska.com
>>http://blog.germuska.com
>>"Narrow minds are weapons made for mass destruction" -The Ex
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Getting Tiles and Chain to play nice together
Posted by Martin Cooper <mf...@gmail.com>.
On Thu, 24 Mar 2005 17:37:05 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> At 1:23 PM -0800 3/24/05, Don Brown wrote:
> >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.
>
> I see your point, but I still think needing to explicitly configure
> the TilesPreProcessor for two different view contexts is a hack. It
> has the bad-code smell that makes me think that we need to
> re-engineer something -- even if I don't know what.
Perhaps what we need is the concept of a "path resolver" that takes a
virtual path and turns it into a real path. The default would be
passthrough, but it would be pluggable in some way so that Tiles (or
stxx or whatever) could register with it and be given a chance to
resolve, for example, a tile name to a real path. Then we just make
sure that anywhere we're about to do a forward (or an include), we
invoke the path resolver first.
Does that make any sense?
--
Martin Cooper
> If you put your .tiles paths all under /WEB-INF/ then wouldn't you
> achieve the same kind of protection that people who put JSPs there
> do? It seems like that should work, although that's pure
> speculation.
>
> Joe
>
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Getting Tiles and Chain to play nice together
Posted by Don Brown <mr...@twdata.org>.
Joe Germuska wrote:
> At 1:23 PM -0800 3/24/05, Don Brown wrote:
>
>> 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.
>
>
> I see your point, but I still think needing to explicitly configure the
> TilesPreProcessor for two different view contexts is a hack. It has the
> bad-code smell that makes me think that we need to re-engineer something
> -- even if I don't know what.
Agreed.
>
> If you put your .tiles paths all under /WEB-INF/ then wouldn't you
> achieve the same kind of protection that people who put JSPs there do?
> It seems like that should work, although that's pure speculation.
Yeah, that could work but that seems like a hack too. In the cast of
stxx, the paths are not physical paths. For example, I'll forward to
"simple/foo.dox" which matches the "simple/*" pipeline. I suppose I
could make that "/WEB-INF/simple/foo.dox" then match the additional
prefix, but that seems like an ugly hack and quite confusing.
Still, I'm not very helpful as I don't have a good solution. The stxx
chain adaption I'm using doesn't account for exceptions thrown.
Don
>
> Joe
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Getting Tiles and Chain to play nice together
Posted by Joe Germuska <Jo...@Germuska.com>.
At 1:23 PM -0800 3/24/05, Don Brown wrote:
>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.
I see your point, but I still think needing to explicitly configure
the TilesPreProcessor for two different view contexts is a hack. It
has the bad-code smell that makes me think that we need to
re-engineer something -- even if I don't know what.
If you put your .tiles paths all under /WEB-INF/ then wouldn't you
achieve the same kind of protection that people who put JSPs there
do? It seems like that should work, although that's pure
speculation.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Getting Tiles and Chain to play nice together
Posted by Don Brown <do...@gmail.com>.
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 <Jo...@germuska.com> 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
> Joe@Germuska.com
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Getting Tiles and Chain to play nice together
Posted by Joe Germuska <Jo...@Germuska.com>.
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
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Getting Tiles and Chain to play nice together
Posted by David Geary <sa...@earthlink.net>.
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 Joe@Germuska.com http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Getting Tiles and Chain to play nice together
Posted by Joe Germuska <Jo...@Germuska.com>.
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.
David G, or anyone: is there a reason that the TilesServlet class was
removed from the distribution?
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
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org