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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]