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 [EMAIL PROTECTED] 734-615-1419 -------------------------------------------- > -----Original Message----- > From: Endre Stolsvik [mailto:[EMAIL PROTECTED]] > 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-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
