[
https://issues.apache.org/jira/browse/TREQ-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421649#comment-13421649
]
Mck SembWever commented on TREQ-12:
-----------------------------------
{quote}separate packages are fine, but if we move the code to .tiles3.request,
what would be left in .tiles3? Only TilesConfigurer?{quote}
TilesConfigurer and DefaultRendererViewResolver (the latter a subclass of
RendererViewResolver that simply adds the default renderer to
DefinitionRenderer, meaning the RendererViewResolver in .tiles.3.request would
again be clean of tiles framework code).
My question was more if you feel this is necessary? I'm otherwise happy to have
everyone just in one package.
{quote}...uncomfortable with DispatchRequest and the forward/include algorithm
beneath it.{quote}
Yeah I'd forgotten about this:
http://thread.gmane.org/gmane.comp.apache.tiles.devel/263/ and
http://thread.gmane.org/gmane.comp.apache.tiles.devel/302/
The idea is ultimately we can remove DispatchRequestWrapper since
DispatchRenderer would handle either cases of RequestWrapper or
DispatchRequest, so the combination isn't required. But how would
DispatchRequest in turn become a hidden internal or removed? There was
suggestion in moving dispatch(..) to DispatchRenderer (forward first request,
include subsequent) and include/forward to ApplicationContext (a
ViewApplicationContext wrapping context is required to override forward calls
to be includes, if DispatchRenderer has no smart way of seeing a request that
can't be forwarded).
If your
[DispatchRenderer|https://github.com/nlebas/tiles-request/blob/freemarker/tiles-request-api/src/main/java/org/apache/tiles/request/render/DispatchRenderer.java]
comes into the next release then SpringRequest can indeed extend the simpler
DefaultRequestWrapper.
But here spring-web+tiles integration will always be servlet based, these
classes (DispatchRequestWrapper and DispatchRequest) are already public in the
tiles-request-1.0 release, and work on refactoring dispatch/include/forward
methods mean breaking compatibility, so is it important to hide these things
right now?
{quote}... they should be called by the Renderer (perhaps DefinitionRenderer...
the fewer implementation details we expose, the better.{quote}
Agreed.
> Spring integration
> ------------------
>
> Key: TREQ-12
> URL: https://issues.apache.org/jira/browse/TREQ-12
> Project: Tiles Request
> Issue Type: Improvement
> Reporter: Nicolas Le Bas
>
> Spring provides an integration with tiles-2. We need one for tiles-3, i.e.
> integration with the Request API.
> Tentative implementation here:
> https://github.com/nlebas/tiles-request/tree/tiles-spring
--
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
