You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Nils-Helge Garli (JIRA)" <ji...@apache.org> on 2007/06/11 22:16:26 UTC

[jira] Updated: (WW-1645) Move Portlet Support to a Plugin

     [ https://issues.apache.org/struts/browse/WW-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nils-Helge Garli updated WW-1645:
---------------------------------

    Attachment: struts2-portlet-patch-core.diff

Initial suggestion for refactoring portlet support into separate plugin. Involves some refactoring of URL handling. Due to couplings between the URL and Form components (and their superclasses), the URL handling refactoring is quite a "quick fix". 

> 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.0
>            Reporter: Ted Husted
>             Fix For: 2.1.0
>
>         Attachments: struts2-portlet-patch-core.diff
>
>
> ---------- Forwarded message ----------
> From: Don Brown <mr...@twdata.org>
> Date: Jan 15, 2007 12:33 AM
> Subject: Re: [S2] Experimental Features
> To: Struts Developers List <de...@struts.apache.org>
> 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.
-
You can reply to this email to add a comment to the issue online.