You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tiles.apache.org by Antonio Petrelli <an...@gmail.com> on 2007/02/20 15:37:46 UTC
Removing JSP dependencies (TILES-114)
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.
* 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...).
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.
* Replace the type "Object" instead of PageContext in API.
Thoughts?
Ciao
Antonio
Re: Removing JSP dependencies (TILES-114)
Posted by "David H. DeWolf" <dd...@apache.org>.
Antonio Petrelli wrote:
. . .
>> I'm still not convinced that request and response doesn't make sense,
>> but since we've already gone with generic objects for request items
>> (which I like), I could be convinced that we should make number of
>> req/res objects variable as well.
>
> If you think that, for example, FreeMarker needs a request, a response
> and a Writer, then probably you will be "more" convinced :-)
Sold!
> Agreed. For the moment I will refactor the BasicTilesContextFactory to
> work as it works now, but I will open an issue to be sure that will
> address it.
> All I want to do now is using varargs where needed.
Awesome
>
> Thank you
> Antonio
>
Re: Removing JSP dependencies (TILES-114)
Posted by Antonio Petrelli <an...@gmail.com>.
2007/2/23, David H. DeWolf <dd...@apache.org>:
>
>
> Antonio Petrelli wrote:
> > 2007/2/23, David H. DeWolf <dd...@apache.org>:
> >> I guess I look at it differently. What we requires is a request object
> >> and a response object. In jsp, the page context acts as both.
> >
> > What about using varargs then? I mean using the form:
> > render(Object... contextItems, String definition);
>
> Maybe . . .though I think it would have to be:
>
> render(String definition, Object. . .contextItems);
Agreed! I will follow this path then.
> I'm still not convinced that request and response doesn't make sense,
> but since we've already gone with generic objects for request items
> (which I like), I could be convinced that we should make number of
> req/res objects variable as well.
If you think that, for example, FreeMarker needs a request, a response
and a Writer, then probably you will be "more" convinced :-)
> >> I'm not sure how all controllers and view can't comply with that?
> >
> > Mmm... I've got another idea. Think of a TilesContextFactory that
> > cycles through a list of TilesContextFactoryItems (name changeable :-)
> > ), where each of them can recognize only one type of request/response
> > pair, and that return a TilesRequestContext if it recognizes them (or
> > null if not). Suppose that this list can be configurable: I think that
> > we solved all of our problems.
> > Together with varargs we can satisfy all needs.
>
> Yes, I like this idea very much, though I think it remains an
> implementation choice of the container. The basic container should
> definitely use this approach.
Agreed. For the moment I will refactor the BasicTilesContextFactory to
work as it works now, but I will open an issue to be sure that will
address it.
All I want to do now is using varargs where needed.
Thank you
Antonio
Re: Removing JSP dependencies (TILES-114)
Posted by "David H. DeWolf" <dd...@apache.org>.
Antonio Petrelli wrote:
> 2007/2/23, David H. DeWolf <dd...@apache.org>:
>> I guess I look at it differently. What we requires is a request object
>> and a response object. In jsp, the page context acts as both.
>
> What about using varargs then? I mean using the form:
> render(Object... contextItems, String definition);
Maybe . . .though I think it would have to be:
render(String definition, Object. . .contextItems);
I'm still not convinced that request and response doesn't make sense,
but since we've already gone with generic objects for request items
(which I like), I could be convinced that we should make number of
req/res objects variable as well.
>
>> I'm not sure how all controllers and view can't comply with that?
>
> Mmm... I've got another idea. Think of a TilesContextFactory that
> cycles through a list of TilesContextFactoryItems (name changeable :-)
> ), where each of them can recognize only one type of request/response
> pair, and that return a TilesRequestContext if it recognizes them (or
> null if not). Suppose that this list can be configurable: I think that
> we solved all of our problems.
> Together with varargs we can satisfy all needs.
Yes, I like this idea very much, though I think it remains an
implementation choice of the container. The basic container should
definitely use this approach.
>
>> Would you rather introduce a TilesRequest and TilesResponse object?
>
> Absolutely not, the problem is not at TilesRequestContext level, but
> in the original request.
Agreed :)
>
> Antonio
>
>
>>
>> David
>>
>> Antonio Petrelli wrote:
>> > 2007/2/23, David H. DeWolf <dd...@apache.org>:
>> >> 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.
>> >
>> >
>> > Hmm... I don't like the idea of using the concept of request/response
>> > to the PageContext.
>> > Moreover, we should provide a way of considering all possible
>> > combinations of controller (I mean servlet, portlet, etc.) and view
>> > (JSP, FreeMarker...) technologies, and the single factory
>> > (TilesContextFactory) can only help with the most common case.
>> >
>> > Antonio
>> >
>>
>
Re: Removing JSP dependencies (TILES-114)
Posted by Antonio Petrelli <an...@gmail.com>.
2007/2/23, David H. DeWolf <dd...@apache.org>:
> I guess I look at it differently. What we requires is a request object
> and a response object. In jsp, the page context acts as both.
What about using varargs then? I mean using the form:
render(Object... contextItems, String definition);
> I'm not sure how all controllers and view can't comply with that?
Mmm... I've got another idea. Think of a TilesContextFactory that
cycles through a list of TilesContextFactoryItems (name changeable :-)
), where each of them can recognize only one type of request/response
pair, and that return a TilesRequestContext if it recognizes them (or
null if not). Suppose that this list can be configurable: I think that
we solved all of our problems.
Together with varargs we can satisfy all needs.
> Would you rather introduce a TilesRequest and TilesResponse object?
Absolutely not, the problem is not at TilesRequestContext level, but
in the original request.
Antonio
>
> David
>
> Antonio Petrelli wrote:
> > 2007/2/23, David H. DeWolf <dd...@apache.org>:
> >> 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.
> >
> >
> > Hmm... I don't like the idea of using the concept of request/response
> > to the PageContext.
> > Moreover, we should provide a way of considering all possible
> > combinations of controller (I mean servlet, portlet, etc.) and view
> > (JSP, FreeMarker...) technologies, and the single factory
> > (TilesContextFactory) can only help with the most common case.
> >
> > Antonio
> >
>
Re: Removing JSP dependencies (TILES-114)
Posted by "David H. DeWolf" <dd...@apache.org>.
I guess I look at it differently. What we requires is a request object
and a response object. In jsp, the page context acts as both.
I'm not sure how all controllers and view can't comply with that?
Would you rather introduce a TilesRequest and TilesResponse object?
David
Antonio Petrelli wrote:
> 2007/2/23, David H. DeWolf <dd...@apache.org>:
>> 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.
>
>
> Hmm... I don't like the idea of using the concept of request/response
> to the PageContext.
> Moreover, we should provide a way of considering all possible
> combinations of controller (I mean servlet, portlet, etc.) and view
> (JSP, FreeMarker...) technologies, and the single factory
> (TilesContextFactory) can only help with the most common case.
>
> Antonio
>
Re: Removing JSP dependencies (TILES-114)
Posted by Antonio Petrelli <an...@gmail.com>.
2007/2/23, David H. DeWolf <dd...@apache.org>:
> 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.
Hmm... I don't like the idea of using the concept of request/response
to the PageContext.
Moreover, we should provide a way of considering all possible
combinations of controller (I mean servlet, portlet, etc.) and view
(JSP, FreeMarker...) technologies, and the single factory
(TilesContextFactory) can only help with the most common case.
Antonio
Re: Removing JSP dependencies (TILES-114)
Posted by "David H. DeWolf" <dd...@apache.org>.
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 <dd...@apache.org>:
>>
>> 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
>> >
>>
>
Re: Removing JSP dependencies (TILES-114)
Posted by Antonio Petrelli <an...@gmail.com>.
2007/2/23, Antonio Petrelli <an...@gmail.com>:
> 2007/2/23, Antonio Petrelli <an...@gmail.com>:
> > The solution could be letting the TilesContainer expose only methods
> > with TilesRequestContext, moving the "getContextFactory" to the
> > TilesContainer interface and working only with TilesRequestContexts.
>
> I noticed that to accomplish it we need to move TilesRequestContext
> and TilesContextFactory to the API.
Thinking on it another bit, I think it's getting too much complicated,
so I think that the best way to treat the problem is converting
PageContext references to simple Object.
Or have you got some better ideas?
Antonio
Re: Removing JSP dependencies (TILES-114)
Posted by "David H. DeWolf" <dd...@apache.org>.
We could, but that would move a lot of stuff "knowledge" out of the
container. I'll play a little this afternoon and see if I can come up
with any concrete ideas.
Antonio Petrelli wrote:
> 2007/2/23, Antonio Petrelli <an...@gmail.com>:
>> The solution could be letting the TilesContainer expose only methods
>> with TilesRequestContext, moving the "getContextFactory" to the
>> TilesContainer interface and working only with TilesRequestContexts.
>
> I noticed that to accomplish it we need to move TilesRequestContext
> and TilesContextFactory to the API.
>
> Antonio
>
Re: Removing JSP dependencies (TILES-114)
Posted by Antonio Petrelli <an...@gmail.com>.
2007/2/23, Antonio Petrelli <an...@gmail.com>:
> The solution could be letting the TilesContainer expose only methods
> with TilesRequestContext, moving the "getContextFactory" to the
> TilesContainer interface and working only with TilesRequestContexts.
I noticed that to accomplish it we need to move TilesRequestContext
and TilesContextFactory to the API.
Antonio
Re: Removing JSP dependencies (TILES-114)
Posted by Antonio Petrelli <an...@gmail.com>.
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 <dd...@apache.org>:
>
> 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
> >
>
Re: Removing JSP dependencies (TILES-114)
Posted by Antonio Petrelli <an...@gmail.com>.
2007/2/21, David H. DeWolf <dd...@apache.org>:
> 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.
+1
I though that you added the "other" standard:
render(pageContext, definition)
for a reason, but it can easily be converted to:
render(pageContext.getRequest(), pageContext.getResponse(), definition)
This way all the story about a new interface is unnecessary.
> >
> > * Replace the type "Object" instead of PageContext in API.
>
> Or just remove that series of methods, right?
+1 to removal.
Antonio
Re: Removing JSP dependencies (TILES-114)
Posted by "David H. DeWolf" <dd...@apache.org>.
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
>