> * Introduce Unique Portlet Instance IDs
>
> I think we also need to introduce a concept for unique portlet instance
> ids, maybe consisting of a user id, page id and portlet id and sequence
> number in order to be able to implement persistence services that store
> portlet data in a database. (This is just a first idea, maybe this a
> more complex topic.)
Thomas, I ve been working with the persistence service that you implemented.
I now have it working with the new profiler, but there are many issues still
open for me. One is a way to uniquely identify a portlet instance.
I agree that we need a unique key to access a portlet instance based on
portlet and page.
The unique sequence number is also necessary for when you have the same
portlet referenced twice or more on a page.
Is the user id necessary, since the persistence info is stored in session
state associated with a user?
One use case I've come up with is where a portlet needs to keep its state
across a session, for all pages in that session, and other times where it
needs to keep state for a particular page. The one use case I was working
with was for min/max/detach state, which by the way, Kevin already had plans
for if you read through the psml.xsd:
<!--
The state defines whether the portlet should be shown in NORMAL mode,
MAXIMIZED mode, MINIMIZED mode or DETACHED. Not yet implemented.
-->
<element name="skin">
<type>
<element ref="parameter" minOccurs="0" maxOccurs="*"/>
<attribute name="state" type="string" minOccurs="0"
default="NORMAL"/>
</type>
</element>
Think about a common portlet that is used on all pages, such as a Navigator.
It will need to keep its state across all pages.
I see this portlet keeping its state in a 'session' scope. Actually, its not
even a portlet state but a controller state.
What Im getting at is that persistence state may need to be on both
'session' and 'page' - similar to (yet no exactly like) beans in jsp.
Another thing I saw in the persistence impl is that a new persistence
service gets created for each portlet (or controller) that needs it per
page, and that it also stores the RunData internally, which I understand is
not a good thing to do, and I know the overhead of creating lots of little
services is not tuned for performance. I guess that the each of these
persistence service instances are meant to only live for the duration of a
request, took me a while to figure that one out. Thats not how Turbine
services work. I think it would be best if we agreed on a common service
paradigm, although Im open to another type of service if necessary. I've
noticed that we now have three:
1. standard Turbine services
2. a kind of hybrid that Raphael and I started with: the
RegistryManagerService and ProfileManagerService -- which I like, but there
is a real problem with the way interfaces are duplicated
3. the new Service and ServiceFactory defined in portal/service.
-- David
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED]
> Sent: Tuesday, January 09, 2001 11:16 AM
> To: JetSpeed
> Subject: Re: Jetspeed 1.3a2
>
>
>
>
>
> Raphael Luta wrote:
>
> > Now that we have released a new 1.3a1 release that should hopefully
> > dramatically cut down the installation issues of Jetspeed, it's time
> > to really start working on Jetspeed 1.3a2 and what features we should
> > include into this release.
> >
> > My personal target feature list for 1.3a2 is this :
> >
> > - fully catch up with Turbine
> > * upgrade to the latest TDK Turbine
> > * rework the TurbineUser dependent code to be only User dependent
> > * start using ACLs
> > * allow any Turbine templated system for layouts and screens with
> > Velocity as default
>
> Personally, I'd prefer JSPs as the default, but as long as JSPs can
> be used alternatively Velocity as the default is fine.
>
> I'd like to add
>
> * Introduce conditional tracing
> (as soon as Turbine povides the required methods)
>
> > - rework the layout system
> > * integrate templates in the other Jetspeed elements
>
> The template systems we'd support first are JSPs and Velocity, I guess ?
>
> > * rethink the PSML support
>
> I'd like to add
>
> * Introduce Unique Portlet Instance IDs
>
> I think we also need to introduce a concept for unique portlet instance
> ids, maybe consisting of a user id, page id and portlet id and sequence
> number in order to be able to implement persistence services that store
> portlet data in a database. (This is just a first idea, maybe this a
> more complex topic.)
>
> > * use the new Portlet API
> > - redesign the customizer
> > * be layout aware
> > * use some portlet-customization entry points in order to provide
> > portlet level customization.
> > - integrate the new Profiler
> > - clean up the DiskCache
> > - change the current Castor based persistence to something extensible
> >
> > Comments or other features requests are welcome. I'll commit in the
> > CVS a TODO-RELEASE-1.3a2 file just like we've done for 1.3a1. It's
> > too early right now to target a release date but I definitely want it
> > before ApacheCon.
>
> That would be before 4/4/2001. Sounds very reasonable, we should
> definitively have another release before April.
>
> Best regards,
>
> Thomas
>
> Thomas Schaeck
> IBM Pervasive Computing Division
> Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED]
> Address: IBM Deutschland Entwicklung GmbH,
> Schoenaicher Str. 220, 71032 Boeblingen, Germany
>
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/[email protected]/>
> List Help?: [EMAIL PROTECTED]
>
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
