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.
