portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Golden <ggol...@umich.edu>
Subject RE: Portlet API re-implementation
Date Fri, 10 May 2002 13:20:54 GMT
As far as I understand, the "new Portlet API" is still behind closed doors
and is not yet open to public review.  If you know of public access to it,
please let me know!

I think you are referring to the very old now portlet API that is in the
jetspeed cvs proposals area - this is not the new API.  Although, the new
API may be related.

I'm not going to base work on the new API until I see it.  But once it's
real, I'm ready to re-write Jetspeed to be the reference implementation of
it.

The work I need to do now is really a fix to a broken implemention inside
the current 1.3a3 Jetspeed.

- Glenn
 
--------------------------------------------
Glenn R. Golden, Systems Research Programmer
University of Michigan School of Information
ggolden@umich.edu               734-615-1419
--------------------------------------------



> -----Original Message-----
> From: Endre Stolsvik [mailto:Endre@Stolsvik.com] 
> Sent: Friday, May 10, 2002 4:55 AM
> To: Jetspeed Developers List
> Subject: Re: Portlet API re-implementation
> 
> 
> | The burrito satisfies the Portlet API for the Portlet 
> class, and for 
> | all users of the Portlet classes, while preserving the multi-user 
> | nature of
> all
> | three of the ingredients.  The same Portlet class object can be in
> multiple
> | burritos at the same time, will not be modified an any way 
> by any one.  
> | In each burrito, the Portlet class object will have 
> different instance 
> | and registration information.
> |
> | In the same way, the Portlet Registration objects and the Portlet 
> | Instance objects might as well be kept around and used over 
> and over 
> | again, rather that re-built for each request.
> |
> | All three are essentially read-only, except for the Portlet 
> Instance 
> | which support updates, then the update is used from then on.
> 
> 
> Have you  read and analysed the "new API", and preferrably 
> also the "Portlet Programming Guide" for IBM's _new-new_ 
> version of the Jetspeed API? Because that's the whole idea in 
> both of those, but read my earlier emails. I would love if 
> Rapahel Luta would comment too..
> 
> There is a concept of a Portlet class instance (which there 
> are only one if, confer Servlets). Then, portlet class 
> instance + PortletSettings object make up the Concrete 
> Portlet. Portlet Settings are parameters from the 
> administartor. He might make several PortletSettings objects 
> with different parameters, thus making several concrete 
> portlets from one portlet. (And mind you, you might also make 
> several Portlets from one class file, as you can with Servlets).
> 
> Then, concrete portlet + PortletData makes the Concrete 
> Portlet Instance. PortletData is per-user-per-page data (I 
> think..?). The PortletData can only be changed by the portlet 
> itself. The Concrete Portlet Instances "lives" on the pages 
> of user, obviously..
> 
> Then, concrete portlet instance + PortletSession makes User 
> Portlet Instance. This is "one servicing" of a portlet. The 
> PortletSession stores transient data used for ONE rendering 
> of the portlet.
> 
> Hope I understood you somewhat correctly..
> 
> Endre.
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:jetspeed-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>
> 

--
To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>


Mime
View raw message