Move Portlet Support to a Plugin
--------------------------------
Key: WW-1645
URL: https://issues.apache.org/struts/browse/WW-1645
Project: Struts 2
Issue Type: Improvement
Components: Portlet Integration
Affects Versions: 2.0.x
Reporter: Ted Husted
Fix For: 2.1.x
---------- Forwarded message ----------
From: Don Brown <[EMAIL PROTECTED]>
Date: Jan 15, 2007 12:33 AM
Subject: Re: [S2] Experimental Features
To: Struts Developers List <[email protected]>
I got 90% of the way once moving the portlet support out to a plugin,
but there were a couple hardcoded references in the URL component and
another internal class that escapes me ATM, so I backed off. This could
be revisited for 2.1.
Don
Tom Schneider wrote:
> Ted Husted
> whttp://www.netidentity.com/Landing7.aspx?d=dail.com&mp=DomainRedirect&DomainID=18855&CategoryID=101521869rote:
>
>> It would be great if there were a portlet plugin. I have no idea how
>> the support is implemented, but I expect it would not be that easy. :)
> Well, the PortletDispatcher (Jsr168Dispatcher.java) and related
> portlet request support classes would probably be easy to separate
> out. The trick would be the form and url tags which right now have
> specific portlet behavior for building portlet url's. The real
> question is do we want separate tags for portlet urls? If so it might
> be possible to have a subclass of the url and form tag for portlet
> environments. If not, then we'd either have to leave the portlet
> support in core and only use it with the portlet plugin--or find some
> way to override how urls are build in core via the plugin. These are
> the issues that I see based on my limited knowledge of the portlet code.
> Tom
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
