> 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 | | <[EMAIL PROTECTED]> | | Apache Jetspeed Portal Project | | Apache Pluto Portlet Container | *================================* > -----Original Message----- > From: Stijn de Witt [mailto:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
