Instead of passing retrieving the request and response from the
pageContext and passing them through, I would use the pageContext as the
request and response and let the (pluggable) jsp factory recognize it
and create it's context using it instead of the req/res pair.
David
Antonio Petrelli wrote:
Uhm, I tried to use only methods with request/response pairs and I
have strange artifacts in response. Just for an example, the
"testinsertdefinition.jsp" have the following response:
/*SNIP*/
<table border="2" width="300" bordercolor="Gray">
<tr>
<td bgcolor="Blue"><strong>This is the title.
<strong>This is the header</strong>
<div align="center"><b><i>This is a body</i></b></div></strong></td>
</tr>
<tr>
<td></td>
</tr>
<tr>
<td></td>
</tr>
</table>
/*SNAP*/
As you can see, the tiles are rendered in the wrong place. What I did
not consider is that a PageContext is not merely a collection of a
request, a response and a page scope.
The solution could be letting the TilesContainer expose only methods
with TilesRequestContext, moving the "getContextFactory" to the
TilesContainer interface and working only with TilesRequestContexts.
Yes, I know that this means more code to write, but at least
everything is consistent.
Thoughts?
Antonio
2007/2/21, David H. DeWolf <[EMAIL PROTECTED]>:
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
>
