Hello.
It seems to me that calling tiles from a portlet just like we can invoke
a JSP, for example, may be the best way :
getPortletContext().getRequestDispatcher(tiles).include(request, response);
I don't know how Spring MVC or other frameworks do "under the hood".
From the application code point of view, the execution flow is
forwarded to the view renderer, with no concern about how it will be
processed. In a pure servlet context, Spring MVC uses a lot of machinery
of view resolvers to get the good technology to handle the view. I don't
know well how it does in the case of portlets, but I think it sets a
similar servlet to execute the rendering allowing the same frameworks
(JSP, Velocity, Tiles, etc.). For information, its poor support for
Portlet 2.0 makes it a limited candidate for me...
In this perspective, the TilesDispatcherServlet allows the application
code relay the request/response from the portlet to the plateform
dispatcher, and intercepts them to execute the definitions templates.
The ViewPreparer workaround seems to work, but I'm not completely
convinced that it will do it in all cases.
I don't understand what you mean about the dispatcher servlet and why I
should prefer the filter alternative. Does it work better, particularly
for portlet applications ?
Thanks for your help and advices.
Regards.
Ephemeris Lappis
Le 14/08/2012 17:42, Nicolas LE BAS a écrit :
On 12-08-14 02:58 AM, Ephemeris Lappis wrote:
> I've already seen many times this test application, but It doesn't
> give me what I'd like. The test code seems to evaluate an internal
> Tiles class like the TilesContainer, but I don't see anything about
> how the framework resolves view definitions or render them...
That is probably the intented way to use Tiles, by calling the API
directly. Perhaps it's not the best...
How would you like to call to tiles in an ideal world?
portletContext.getRequestDispatcher(definition).include(rq,rs)?
How are other portlet libraries working? Spring Portlet MVC appears to
use requestDispatcher.include, too. Liferay's MVCPortlet seems to be
doing it, too. Do you know other libraries of note?
On 12-08-14 05:57 AM, Ephemeris Lappis wrote:
I've done some new tests, debugging what occurs during the view
rendering. I've found, as already mentioned in other posts, that Tiles
intents to build its content with "forward" instead of "include",
which is why it probably doesn't produce anything...
Great analysis! Indeed when you're using TilesDispatchServlet, you're
using the servlet API, and Tiles tries and optimizes the first
"include" into a "forward" whenever it thinks it's possible.
I've found a post or two that seems to report similar problems, and
giving as a possible solution to configure a ViewPreparer to intercept
the request processing and force Tiles to include the generated
content.
It's a good workaround, although the ViewPreparer needs to be
configured for every definition (which may be relatively easy with
inheritance), and you can only have one ViewPreparer for a given
definition.
If you're going to use TilesDispatchServlet, I'd advise you to use a
ServletFilter: it would be done once and for all, and separates
concerns in a better way.
Hope this helps,
Nick.
