[
https://issues.apache.org/jira/browse/TILES-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13262454#comment-13262454
]
Viktor Hedefalk commented on TILES-544:
---------------------------------------
Hi Nicolas,
thanks for your reply!
I understand that my "solution" breaks the intended purpose and is not
feasible, but it at least points to the problem. I think the inheritance thing
looks upside down and that your second comment seems reasonable. I tried
something like that but for some reason couldn't get it to compile before. I
feel like trying out your second comment, but you say that it's wrong? Reading
the doc of inherit:
{quote}
/**
* Inherits the attribute context, inheriting, i.e. copying if not present,
* the attributes.
*/
{quote}
it really seems to be upside down?
Your last comment seems easier though since I had to do some serious hacking of
Spring to be able to override the method in BasicTilesContainer - TilesView
would be a lot simpler.
{quote}
Now why is spring not doing it? Probably because you're not supposed to pass
control back to the controller after you've started rendering the view; that
breaks the MVC paradigm and Spring is not designed for that.
{quote}
About the MVC thing - I definitely have no philosophical standpoint on MVC, I
never really connected to it in the first place :) But it seems a lot harder to
compose MVC if I can't to that. Note that I'm not passing back control to the
original controller though, but to the controllers of the included resources.
If I couldn't do that, what would then be needed is for the surrounding
controller to delegate to the other controllers directly, letting them fill out
some backing bean structure that then the surrounding view could traverse and
delegate to the included views. That breaks up the composition in two different
places. THAT I would consider broken. Maybe there's a cleaner solution I'm
missing?
Basically I think it sounds weird that Spring is not designed for this. To use
JSP:s as views must then be considered extreeeemely dangerous.
Isn't any kind of mashup a breach of that strict idea? An <img> tag in the view
pointing to a dynamically rendered image would be too, only you have different
http-requests to protect you… Maybe I'm misinterpreting…
Thanks!
> Stack overflow due to rendering loop when including a resource resulting in
> another tiles view.
> -----------------------------------------------------------------------------------------------
>
> Key: TILES-544
> URL: https://issues.apache.org/jira/browse/TILES-544
> Project: Tiles
> Issue Type: Bug
> Affects Versions: 2.2.2
> Environment: Spring MVC 3.1.1
> Reporter: Viktor Hedefalk
> Attachments: tiles-stackoverflow.txt
>
>
> I get a stackoverflow because of a rendering loop when including an call to a
> controller with a view is also a tile. This is a dup of TILES-418, but since
> that one was closed and I couldn't attach my stack trace, I'll open this new
> one.
> To me this is very critical. I just upgraded an application from Spring 2.0.7
> and old struts-tiles to Spring 3.1.1 and tiles 2.2.2 and the structure worked
> with struts-tiles. It's kind of a homebrew portlet thingy where we iterate
> over url:s pointing to controllers given by a cms.
> The included controller is called correctly and returns a model and view
> where the view points to a tile definition. But when Spring gives over the
> rendering to tiles, the loop begins.
> It doesn't matter if I include the url with:
> <tiles:insertTemplate name="${entry.url}" />
> or
> <c:import url="${entry.url }" />
> the same error occurs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
