Antonio Petrelli wrote:
Hi!
I have filed a JIRA issue about the removal of JSP dependencies and,
following David's suggestion, I am starting a thread about find a good
approach to solve this issue.
http://issues.apache.org/struts/browse/TILES-114
Thinking out a bit I think that we may:
* create "TilesPageContext" class, extending from
"TilesRequestContext", plus a "getPageScope" method.
What's the purpose of this new interface, it seems page specific? Or,
do you mean that this is a JSP specific implementation of the
TilesRequestContext? How would the getPageScope be used internally?
* create a "TilesPageContextFactory" that creates a TilesPageContext
from an object (in the case of JSP it is a PageContext).
The two factories should be separated because TilesContextFactory
creates contexts from the "controller" technology (servlet, portlet,
etc.), while TilesPageContextFactory creates it from "view" technology
(JSP, FreeMarker...).
Ok, I think this answers my previous question :). You really do mean a
new interface, so I'm not sure how it'd be used. Are you suggesting
that there would be two types of container methods:
For controllers:
render(request, response, definitionName)
and for view technologies:
render(object, definitionName)
If so, why do we need the seperation? Why not just make the
TilesContextFactory implementation for jsp smart enough to convert the
pageContext into a TilesRequestContext? We could pass the PageContext
as both the request and the response. I'm not sure I understand the need
for view technology specific features here? Is it just a convenience?
This is OK for JSP, but maybe for Velocity and FreeMarker it is a
problem, since I suppose that a "Velocity PageContext" is made of a
context for velocity plus request plus response (the same for
FreeMarker). I suppose that varargs is not a viable choice.
Keeping things to the standard:
render(request, response, definition) and forcing the factories to
handle them consistently, allows us to centralize the burden of creating
the context on the factory.
* Replace the type "Object" instead of PageContext in API.
Or just remove that series of methods, right?
Thoughts?
Ciao
Antonio
