You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Nils-Helge Garli <ni...@gmail.com> on 2007/06/11 22:22:35 UTC
Re: Portlet plugin
I have finally been able to extract the portlet code into a plugin,
but it required some "shortcuts" due to couplings between the
Components (URL, Form and it's super classes) and generating the URLs.
But at least all tests pass, and there are no more dependencies to the
portlet API in the core. I have attached the files as patches to the
JIRA ticket (https://issues.apache.org/struts/browse/WW-1645), since
it needs a review and probably some discussion.
Nils-H
On 4/11/07, Nils-Helge Garli <ni...@gmail.com> wrote:
> I have started the process of moving the portlet code to a plugin. But
> any further progress requires the url building abstraction discussed
> earlier. What is the status for this code?
>
> Also, I think the code in general would benefit from a common
> abstraction of the servlet- and portlet types (request, response,
> context etc). It would most certainly reduce the amount of "almost
> duplicated" code needed to operate Struts in a portlet.
>
> Nils-H
>
> On 3/26/07, Ted Husted <hu...@apache.org> wrote:
> > The trunk is the correct place (we branched for 2.0.x).
> >
> > On 3/25/07, Nils-Helge Garli <ni...@gmail.com> wrote:
> > > Hi!
> > >
> > > I want to start looking into moving the portlet support to a plugin,
> > > but need a little guidance to get started.
> > >
> > > - What is the status of refactoring the URL-building, as discussed in
> > > previous mail threads?
> > > - From what I understand, a "hook" for injecting a URL builder
> > > implementation from the plugin must be provided. How is that achieved?
> > > - Is trunk the correct place to work on, or will a 2.1.x branch be created?
> > >
> > > Nils-H
> >
> > ---------------------------------------------------------------------
> > 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: Portlet plugin
Posted by Nils-Helge Garli <ni...@gmail.com>.
Thanks for the feedback!
On 6/12/07, Tom Schneider <sc...@gmail.com> wrote:
> 1. I'm not sure the UrlRendererFactory is needed. I believe the whole
> purpose of guice is to not have anymore factories anymore, so guice
> should just inject the necessary UrlRenderer. (especially if they are
> stateless)
Ah....of course... I just saw some other "factories" when trying to
figure out how the injection works, and assumed wrong. I'll remove
them.
>
> 2. As a first step in separating out the url building logic I like how
> you have the form url building seperate from the typical url building.
> I tried to combine these and couldn't find a clean way to resolve the
> differences.
>
> HTH,
> Tom
Yeah, I couldn't find a way to combine them either. So I think
separating them, for now, is the easiest route to go.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Portlet plugin
Posted by Tom Schneider <sc...@gmail.com>.
Nils,
This is a great start. I had wanted to do this myself, but I never
found the time. I only took a brief look at the patch, but a few things
jumped out at me:
1. I'm not sure the UrlRendererFactory is needed. I believe the whole
purpose of guice is to not have anymore factories anymore, so guice
should just inject the necessary UrlRenderer. (especially if they are
stateless)
2. As a first step in separating out the url building logic I like how
you have the form url building seperate from the typical url building.
I tried to combine these and couldn't find a clean way to resolve the
differences.
HTH,
Tom
> I have finally been able to extract the portlet code into a plugin,
> but it required some "shortcuts" due to couplings between the
> Components (URL, Form and it's super classes) and generating the URLs.
> But at least all tests pass, and there are no more dependencies to the
> portlet API in the core. I have attached the files as patches to the
> JIRA ticket (https://issues.apache.org/struts/browse/WW-1645), since
> it needs a review and probably some discussion.
>
> Nils-H
>
> On 4/11/07, Nils-Helge Garli <ni...@gmail.com> wrote:
>> I have started the process of moving the portlet code to a plugin. But
>> any further progress requires the url building abstraction discussed
>> earlier. What is the status for this code?
>>
>> Also, I think the code in general would benefit from a common
>> abstraction of the servlet- and portlet types (request, response,
>> context etc). It would most certainly reduce the amount of "almost
>> duplicated" code needed to operate Struts in a portlet.
>>
>> Nils-H
>>
>> On 3/26/07, Ted Husted <hu...@apache.org> wrote:
>> > The trunk is the correct place (we branched for 2.0.x).
>> >
>> > On 3/25/07, Nils-Helge Garli <ni...@gmail.com> wrote:
>> > > Hi!
>> > >
>> > > I want to start looking into moving the portlet support to a plugin,
>> > > but need a little guidance to get started.
>> > >
>> > > - What is the status of refactoring the URL-building, as
>> discussed in
>> > > previous mail threads?
>> > > - From what I understand, a "hook" for injecting a URL builder
>> > > implementation from the plugin must be provided. How is that
>> achieved?
>> > > - Is trunk the correct place to work on, or will a 2.1.x branch
>> be created?
>> > >
>> > > Nils-H
>> >
>> > ---------------------------------------------------------------------
>> > 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