David,
thanks for your comments. See responses below. Unfortunately, I was
in a hurry because we currently have an urgent project, so I couldn't
dig into things very deeply. We surely have to spend more time thinking
of these topics, especially unification of service APIs and how to
introduce the portlet instance ids.
David Sean Taylor wrote:
> > * 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?
The persistence service uses the session only as a write-through cache.
The essential function of the persistence service is to store data like
e.g.
portlet settings in files (like the current default implementation) or in
databases. To retrieve portlet settings, a query must be made to the
database
that includes <user id, page id, portlet id, sequence number>.
> 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.
I think that's a different topic. For handling that, we might introduce a
PortletSession object into which portlets can put objects like a controller
state, beans or whatever. This data does not need to be persistent, though.
I agree that the user id is not required to access this data, as it is
implicitly bound to a user by being stored in the user's session.
> 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.
The RunData usage definitively needs to disappear when we introduce the
new portlet API. The concept behind the persistence service interface is
to keep open how the actual implementation works. The we have provided as
a start doesn't create new instances all the time. Each time you call the
method for getting a service instance from the same session, you get the
same service implementation object.
> 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.
The user (e.g. a portlet) of a service should obtain a service reference
per request. Depending on the service implementation, this may be a
reference to a new object for each call or a reference to the same service
object all the time.
It's up to service implementations to determine the life time of service
objects. For the persistence service implementation we provided, the life
time of the persistence service object conceptually is infinite (also the
"physical" Java object lifetime of course ends with the session).
However, for a location service that provides the current location, the
conceptual lifetime may be the duration of processing one request, as at
the time of the next request the location may be different if the user is
moving, e.g. in a train.
> 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
It would surely be good if we could unify the different service concepts.
I think we should not directly use Turbine services for services that are
basically extensions to the portlet API, like persistence, user info and
location. This would tie the Portlet API to the JetSpeed implementation.
The Portlet API has to be selfcontained and may only rely on J2EE, so that
portals other than JetSpeed may implement the same API in a different way.
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]
