portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weaver, Scott" <Swea...@rippe.com>
Subject RE: Jetspeed 1 and 2 questions
Date Mon, 03 Nov 2003 16:37:36 GMT
> Do you mean that when I move my code to Jetspeed 2, I take the actions for
> the GenericMVCPortlet and put them in a new class which descends from some
> base Jetspeed 2 portlet?

I would just copy my doXyz event methods to a new portlet class implementing extending javax.portlet.GenericPortlet
or a subclass there off. Then add logic to the GenericPortlet.processAction() so it delegates
to the correct event method based on the "eventSubmit_*" request parameter.  This should be
very easy to put together using commons-beanutils.

As for the buildNormalContext, buildMaximizedContext and buildConfigureContext, you should
be able to map these to the corresponding methods set forth by the portlet spec.

buildNormalContext would be equivalent to javax.portlet.WindowState.NORAML and the javax.portlet.GenericPortlet.doView(RenderRequest,
RenderResponse) method.

buildMaximizedContext would be equivalent to javax.portlet.WindowState.MAXIMIZED.

buildConfiugreContext would be equivalent to javax.portlet.GenericPortlet.doEdit(RenderRequest,
RenderResponse) and javax.portlet.WindowState.MAXIMIZED.

As for the registry, it would be nice if someone stepped up and wrote an XSL to transform
the J1 registry to a standard portlet.xml deployment descriptor.


Regards,
*================================* 
| Scott T Weaver                 |
| <weaver@apache.org>            | 
| Apache Jetspeed Portal Project |
| Apache Pluto Portlet Container |
*================================*


> -----Original Message-----
> From: Stijn de Witt [mailto:Stijn.deWitt@bergland-it.nl]
> Sent: Monday, November 03, 2003 11:08 AM
> To: Jetspeed Developers List
> Subject: Re: Jetspeed 1 and 2 questions
> 
> > > Can anyone shed some light on what to do (or don't) if developing for
> > > Jetspeed 1, to keep the upgrade path to Jetspeed 2 simple...?
> >
> > Follow a loose coupling model.  Try and keep as much of your business
> logic out of the components that are tightly bound to Jetspeed 1.
> >
> 
> Ok, that makes sense.. :p
> 
> 
> > My approach has always been to:
> >
> > - NEVER create a portlet class, just use the GenericMVCPortlet along
> with
> a
> >   portlet action.
> > - Keep portlet actions as small possible.  Eventually, we will have
> special
> >   adapter class(es) that you will be able to drop on top of existing J1
> >   portlets.  However, the "best practice" approach would be to move your
> >   portlet action's logic straight into a JSR-168 portlet.  This should
> be
> >   relatively simple if you keep the actions lightweight.
> 
> Do you mean that when I move my code to Jetspeed 2, I take the actions for
> the GenericMVCPortlet and put them in a new class which descends from some
> base Jetspeed 2 portlet?
> 
> 
> > - Use a service model as it will be very easy to move current Jetspeed
> >   (fulcrum) into a portlet app using the stand-alone Fulcrum framework.
> >
> 
> Thanks for your quick reaction Scott!
> 
> Greetings, Stijn
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org





Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message