You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Tom Schneider <sc...@gmail.com> on 2007/01/21 17:22:44 UTC
[s2] Pluggable URL building proposal
Based on the portlet plugin proposal and some work I've been doing with
the table tags, I thought I would propose a refactor of the URL building
for struts2. Right now, struts2 has great support for taking on
incoming request and mapping it to the core elements of the framework
(i.e. namespace, action, method, etc.) in the ActionMapper interface.
It seems like we should be doing the same for building URL's. This
would allow the url tag to be completely dumb about how url's are built
up. Right now, the url tag has specific logic to determine if the
request is a portlet request or not and uses PortletUrlHelper or
UrlHelper respectively. If the url building was pluggable, we would
have a default url builder that would be configured to build either
portlet url's or regular url's. This would allow us to easily extract
the portlet support out into a separate plugin. It would also allow 3rd
part tags (like table tags) transparent, built-in portlet support with
almost no effort. We could also support other types of url's like
Restful urls. (Right now, I'm not sure how the url tag supports restful
url's)
I'll take a preliminary look at this later today, but I was curious if
anyone thoughts, pro or con regarding this.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Pluggable URL building proposal
Posted by Tom Schneider <sc...@gmail.com>.
Hey Patrick,
Haven't had time to look at this any further. Yes, I definitely would build
on top of the ActionMapper stuff--that's already abstracted out so nicely I
didn't even mention it. :) I might have some time this weekend to dig into
this further. (I was too busy releasing the first version of table tags
this weekend to look at this)
Tom
On 1/31/07, Patrick Lightbody <fo...@opensymphony.com> wrote:
>
> Tom,
> How is this coming along? I imagine that some of this work would also
> relate to the ActionMapper interface, since it does have some
> responsibilities for rendering out URLs. Keep us posted.
> ---------------------------------------------------------------------
> Posted via Jive Forums
>
> http://forums.opensymphony.com/thread.jspa?threadID=59916&messageID=119811#119811
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: [s2] Pluggable URL building proposal
Posted by Tom Schneider <sc...@gmail.com>.
Ok, I've decided to prototype the urlbuilder in tabletags. (Getting s2
all converted over would've taken too much time) So I've checked in the
basic servlet/portlet url builders here:
http://tabletags.googlecode.com/svn/trunk/tags/src/main/java/com/googlecode/tabletags/urlbuilder/
I'd appreciate any feedback. Once we've worked out all the kinks, we
can look at integrating into the full struts2 codebase.
Tom
Tom Schneider wrote:
> I am very ashamed to report that I didn't get very far. (too much
> snow to shovel last weekend) I was able to analyze what each type of
> url would need, i.e. portlet vs. normal url. I think our best best is
> to have a data bean that encapsulates non-stardard stuff for each url
> type along with a seperate bean that captures the standard stuff.
>
> Generic stuff:
> action
> namespace
> method
> scheme
> anchor
> includeParams
>
> Portlet specific data:
> portletMode
> portletUrlType
>
> This is just a start, but it gives you an idea of what I'm thinking.
> I also noticed how asymmetric the PortalURLHelper and the URLHelper
> are. Most of the refactoring would probably happen in these classes,
> so the final API would probably be something of a mix between the 2.
> Just some random thoughts for you to chew on. I'll post more if I
> find some time to look into this some more. I'd like to come up with
> a proposed API for everyone (mostly me and you Don) to review. Once
> we agree on that, the implementation should be pretty straightforward.
> Tom
>
> Don Brown wrote:
>> I _love_ this idea as it is been something I've wanted to tackle
>> myself for a while now. I'm very interested in your progress, so let
>> us know what you find.
>>
>> Don
>>
>> Tom Schneider wrote:
>>> Based on the portlet plugin proposal and some work I've been doing
>>> with the table tags, I thought I would propose a refactor of the URL
>>> building for struts2. Right now, struts2 has great support for
>>> taking on incoming request and mapping it to the core elements of
>>> the framework (i.e. namespace, action, method, etc.) in the
>>> ActionMapper interface. It seems like we should be doing the same
>>> for building URL's. This would allow the url tag to be completely
>>> dumb about how url's are built up. Right now, the url tag has
>>> specific logic to determine if the request is a portlet request or
>>> not and uses PortletUrlHelper or UrlHelper respectively. If the url
>>> building was pluggable, we would have a default url builder that
>>> would be configured to build either portlet url's or regular url's.
>>> This would allow us to easily extract the portlet support out into a
>>> separate plugin. It would also allow 3rd part tags (like table
>>> tags) transparent, built-in portlet support with almost no effort.
>>> We could also support other types of url's like Restful urls.
>>> (Right now, I'm not sure how the url tag supports restful url's)
>>>
>>> I'll take a preliminary look at this later today, but I was curious
>>> if anyone thoughts, pro or con regarding this.
>>> Tom
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Pluggable URL building proposal
Posted by Nils-Helge Garli <ni...@gmail.com>.
I like the JSR168 approach to URLs, where URLs are objects. So if URL
was an interface, with two concrete implementations (one for servlet
and one for portlet), URL manipulation would be very flexible and easy
(e.g. addParameter, setAttribute etc), and rendering the URL as a
String
would be nothing more than invoking the toString() method. This could
be especially convenient in a portlet, since the framework might need
to modify the URLs to add state information before it is rendered.
Nils-H
On 2/5/07, Don Brown <mr...@twdata.org> wrote:
> Cool, but please, please, please find some way to avoid a static helper
> class :) BTW, it would be cool if the urlbuilder would be able to
> automatically discover any other objects that want a shot at the URL
> building process. See how the TagLibrary or TemplateEngine classes are
> discovered for examples.
>
> Don
>
> Tom Schneider wrote:
> > Ok, I had a little time tonight to put together a preliminary design
> > for the URLBuilder. Here's what I have so far for the interface:
> >
> > URLBuilder
> > +buildURL(CustomAttributes, ActionMapping) // this method is for when
> > an action, namespace, method, etc. is supplied
> > +buildURL(CustomAttributes, String) // this method is for when the
> > url value itself is provided
> >
> > My expectation is each builder would use the default ActionMapper
> > under the hood. From an infrastructure standpoint, it would be
> > configured and injected the same as the ActionMapper is.
> >
> > The custom attributes that I've come up with so far are:
> > CustomPortletAttributes:
> > RenderRequest, RenderResponse
> > windowState
> > portletUrlType
> > portletMode
> >
> > CustomServletAttributes:
> > HttpServletRequest, HttpServletResponse
> > encodeParams
> > includeContext
> > scheme
> >
> > I'm not exactly sure how we'll build these up. Either the client code
> > of the builder will have to know how to build each type or we'll need
> > a static helper class that does most of the work. I'll probably be
> > taking a stab at implementation this weekend.
> > Tom
> >
> >
> > Patrick Lightbody wrote:
> >> Tom,
> >> How is this coming along? I imagine that some of this work would also
> >> relate to the ActionMapper interface, since it does have some
> >> responsibilities for rendering out URLs. Keep us posted.
> >> ---------------------------------------------------------------------
> >> Posted via Jive Forums
> >>
> http://forums.opensymphony.com/thread.jspa?threadID=59916&messageID=119811#119811
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Pluggable URL building proposal
Posted by Tom Schneider <sc...@gmail.com>.
Yes, I've already implemented that piece of it. The UrlBuilder
implementation can automatically be injected via the @Inject annotation,
just like the actionmapper. Right now my ServletUrlBuilder and
PortletUrlBuilder use the static UrlHelper and PortletUrlHelper under
the hood, but eventually we could move that logic into the builders
themselves.
Tom
Don Brown wrote:
> Cool, but please, please, please find some way to avoid a static
> helper class :) BTW, it would be cool if the urlbuilder would be able
> to automatically discover any other objects that want a shot at the
> URL building process. See how the TagLibrary or TemplateEngine
> classes are discovered for examples.
>
> Don
>
> Tom Schneider wrote:
>> Ok, I had a little time tonight to put together a preliminary design
>> for the URLBuilder. Here's what I have so far for the interface:
>>
>> URLBuilder
>> +buildURL(CustomAttributes, ActionMapping) // this method is for
>> when an action, namespace, method, etc. is supplied
>> +buildURL(CustomAttributes, String) // this method is for when the
>> url value itself is provided
>>
>> My expectation is each builder would use the default ActionMapper
>> under the hood. From an infrastructure standpoint, it would be
>> configured and injected the same as the ActionMapper is.
>>
>> The custom attributes that I've come up with so far are:
>> CustomPortletAttributes:
>> RenderRequest, RenderResponse
>> windowState
>> portletUrlType
>> portletMode
>>
>> CustomServletAttributes:
>> HttpServletRequest, HttpServletResponse
>> encodeParams
>> includeContext
>> scheme
>>
>> I'm not exactly sure how we'll build these up. Either the client
>> code of the builder will have to know how to build each type or we'll
>> need a static helper class that does most of the work. I'll probably
>> be taking a stab at implementation this weekend.
>> Tom
>>
>>
>> Patrick Lightbody wrote:
>>> Tom,
>>> How is this coming along? I imagine that some of this work would
>>> also relate to the ActionMapper interface, since it does have some
>>> responsibilities for rendering out URLs. Keep us posted.
>>> ---------------------------------------------------------------------
>>> Posted via Jive Forums
>>> http://forums.opensymphony.com/thread.jspa?threadID=59916&messageID=119811#119811
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Pluggable URL building proposal
Posted by Don Brown <mr...@twdata.org>.
Cool, but please, please, please find some way to avoid a static helper
class :) BTW, it would be cool if the urlbuilder would be able to
automatically discover any other objects that want a shot at the URL
building process. See how the TagLibrary or TemplateEngine classes are
discovered for examples.
Don
Tom Schneider wrote:
> Ok, I had a little time tonight to put together a preliminary design
> for the URLBuilder. Here's what I have so far for the interface:
>
> URLBuilder
> +buildURL(CustomAttributes, ActionMapping) // this method is for when
> an action, namespace, method, etc. is supplied
> +buildURL(CustomAttributes, String) // this method is for when the
> url value itself is provided
>
> My expectation is each builder would use the default ActionMapper
> under the hood. From an infrastructure standpoint, it would be
> configured and injected the same as the ActionMapper is.
>
> The custom attributes that I've come up with so far are:
> CustomPortletAttributes:
> RenderRequest, RenderResponse
> windowState
> portletUrlType
> portletMode
>
> CustomServletAttributes:
> HttpServletRequest, HttpServletResponse
> encodeParams
> includeContext
> scheme
>
> I'm not exactly sure how we'll build these up. Either the client code
> of the builder will have to know how to build each type or we'll need
> a static helper class that does most of the work. I'll probably be
> taking a stab at implementation this weekend.
> Tom
>
>
> Patrick Lightbody wrote:
>> Tom,
>> How is this coming along? I imagine that some of this work would also
>> relate to the ActionMapper interface, since it does have some
>> responsibilities for rendering out URLs. Keep us posted.
>> ---------------------------------------------------------------------
>> Posted via Jive Forums
>> http://forums.opensymphony.com/thread.jspa?threadID=59916&messageID=119811#119811
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Pluggable URL building proposal
Posted by Tom Schneider <sc...@gmail.com>.
Ok, I had a little time tonight to put together a preliminary design for
the URLBuilder. Here's what I have so far for the interface:
URLBuilder
+buildURL(CustomAttributes, ActionMapping) // this method is for when
an action, namespace, method, etc. is supplied
+buildURL(CustomAttributes, String) // this method is for when the url
value itself is provided
My expectation is each builder would use the default ActionMapper under
the hood. From an infrastructure standpoint, it would be configured and
injected the same as the ActionMapper is.
The custom attributes that I've come up with so far are:
CustomPortletAttributes:
RenderRequest, RenderResponse
windowState
portletUrlType
portletMode
CustomServletAttributes:
HttpServletRequest, HttpServletResponse
encodeParams
includeContext
scheme
I'm not exactly sure how we'll build these up. Either the client code
of the builder will have to know how to build each type or we'll need a
static helper class that does most of the work. I'll probably be taking
a stab at implementation this weekend.
Tom
Patrick Lightbody wrote:
> Tom,
> How is this coming along? I imagine that some of this work would also relate to the ActionMapper interface, since it does have some responsibilities for rendering out URLs. Keep us posted.
> ---------------------------------------------------------------------
> Posted via Jive Forums
> http://forums.opensymphony.com/thread.jspa?threadID=59916&messageID=119811#119811
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Pluggable URL building proposal
Posted by Patrick Lightbody <fo...@opensymphony.com>.
Tom,
How is this coming along? I imagine that some of this work would also relate to the ActionMapper interface, since it does have some responsibilities for rendering out URLs. Keep us posted.
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=59916&messageID=119811#119811
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Pluggable URL building proposal
Posted by Tom Schneider <sc...@gmail.com>.
I am very ashamed to report that I didn't get very far. (too much snow
to shovel last weekend) I was able to analyze what each type of url
would need, i.e. portlet vs. normal url. I think our best best is to
have a data bean that encapsulates non-stardard stuff for each url type
along with a seperate bean that captures the standard stuff.
Generic stuff:
action
namespace
method
scheme
anchor
includeParams
Portlet specific data:
portletMode
portletUrlType
This is just a start, but it gives you an idea of what I'm thinking. I
also noticed how asymmetric the PortalURLHelper and the URLHelper are.
Most of the refactoring would probably happen in these classes, so the
final API would probably be something of a mix between the 2. Just some
random thoughts for you to chew on. I'll post more if I find some time
to look into this some more. I'd like to come up with a proposed API
for everyone (mostly me and you Don) to review. Once we agree on that,
the implementation should be pretty straightforward.
Tom
Don Brown wrote:
> I _love_ this idea as it is been something I've wanted to tackle
> myself for a while now. I'm very interested in your progress, so let
> us know what you find.
>
> Don
>
> Tom Schneider wrote:
>> Based on the portlet plugin proposal and some work I've been doing
>> with the table tags, I thought I would propose a refactor of the URL
>> building for struts2. Right now, struts2 has great support for
>> taking on incoming request and mapping it to the core elements of the
>> framework (i.e. namespace, action, method, etc.) in the ActionMapper
>> interface. It seems like we should be doing the same for building
>> URL's. This would allow the url tag to be completely dumb about how
>> url's are built up. Right now, the url tag has specific logic to
>> determine if the request is a portlet request or not and uses
>> PortletUrlHelper or UrlHelper respectively. If the url building was
>> pluggable, we would have a default url builder that would be
>> configured to build either portlet url's or regular url's. This
>> would allow us to easily extract the portlet support out into a
>> separate plugin. It would also allow 3rd part tags (like table tags)
>> transparent, built-in portlet support with almost no effort. We
>> could also support other types of url's like Restful urls. (Right
>> now, I'm not sure how the url tag supports restful url's)
>>
>> I'll take a preliminary look at this later today, but I was curious
>> if anyone thoughts, pro or con regarding this.
>> Tom
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Pluggable URL building proposal
Posted by Don Brown <mr...@twdata.org>.
I _love_ this idea as it is been something I've wanted to tackle myself
for a while now. I'm very interested in your progress, so let us know
what you find.
Don
Tom Schneider wrote:
> Based on the portlet plugin proposal and some work I've been doing
> with the table tags, I thought I would propose a refactor of the URL
> building for struts2. Right now, struts2 has great support for taking
> on incoming request and mapping it to the core elements of the
> framework (i.e. namespace, action, method, etc.) in the ActionMapper
> interface. It seems like we should be doing the same for building
> URL's. This would allow the url tag to be completely dumb about how
> url's are built up. Right now, the url tag has specific logic to
> determine if the request is a portlet request or not and uses
> PortletUrlHelper or UrlHelper respectively. If the url building was
> pluggable, we would have a default url builder that would be
> configured to build either portlet url's or regular url's. This would
> allow us to easily extract the portlet support out into a separate
> plugin. It would also allow 3rd part tags (like table tags)
> transparent, built-in portlet support with almost no effort. We could
> also support other types of url's like Restful urls. (Right now, I'm
> not sure how the url tag supports restful url's)
>
> I'll take a preliminary look at this later today, but I was curious if
> anyone thoughts, pro or con regarding this.
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org