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 15:46:17 GMT
> 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.  

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.
- 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.



HTH,
*================================* 
| 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 10:19 AM
> To: jetspeed-dev@jakarta.apache.org
> Subject: Jetspeed 1 and 2 questions
> 
> Can anyone tell me please how far development of jetspeed 2 is and how the
> transition from Jetspeed 1 to Jetspeed 2 is planned? I was planning on
> basing my developments on Jetspeed, but now that I know that Jetspeed 2
> will be very different from 1, I don't know what I am going to do...
> 
> 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...?
> 
> Thanks,
> 
> Stijn

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