wsrp message

Subject: Re: [wsrp][interfaces]: Portal Usage Scenario

From: Dave Clegg <davec@sybase.com>
To: Michael Freedman <Michael.Freedman@oracle.com>
Date: Tue, 16 Apr 2002 14:53:15 -0700

1. If no user is  seeing no portal page at a certain
point in time, does a portlet instance  exist at that time?

Answers:( X ) Yes

Some persistent customization or state information is associated with this thing, so it has to "exist" in some serialized state as a logical entity.


( ) No

( ) Other:
____________________________________________________________________

2. If a
user is  seeing a portal page at a certain point in time, is it the portlet
instance which is rendering the  portlet?

Answers:(  ) Yes

( X ) No

Rendering implies executable code. Seriously doubt that anybody is going to be generating "instance-specific" code of any sort, and further think it higly unlikely that there will be any custom code in the Consumer (Portal) on a per-portlet basis. Instead, there is some rendering engine that accesses the instance data from the Portlet Instance and invoking the service using WSRP protocols as necessary. At the point of execution, there is likely some Entity Bean or simple Java Bean that provides object-oriented access to the instance data, but no behavioral code would be found there (unless it is inherited, which probably would be a bad OO design).

( ) Other:

I've been thinking thru how some of this binding, templating, re-templating, and end-user customization might play out. I drew up the following object diagram (forgive the designy nature of such a thing at this early stage, but it helps me think things out).
oo model

Customization of a portlet involves specification of a SET of customization properties.
The full range of this set is defined by the portlet's metadata.
Part of the information in that metadata for particular items should indicate who is responsible for setting and maintaining that customization information. I've modelled this as the DataItemInfo object in the diagram. Among the considerations for this

Some customizations are "locked" in at the Provider side (perhaps as part of a negotiated contract between the provider owner and the consumer owner). This is the "Overrideable" attribute of DataItemInfo.
Some customizations are "required" to be provided by the Consumer (it doesn't make sense for a stock-ticker portlet to define the list of stocks to watch). The "Required" attribute
Some customizations may be settable by either (if the consumer provides a customization it simply overrides the default customization defined by the producer).
For each item we need to know whether the producer or consumer is responsible for persisting the customized value (PersistenceLocation attribute).

If the producer saves it, do we need accessors so the consumer can peek at it as necessary?
If the consumer saves it we need to know whether the customizer value needs to be passed to the producer with every operation of if there is a transient cache that can be populated ones (like a stateful session bean that can timeout).
If both are able to save it we need to determine the mechanism for synchronizing the "correct" value between them - we have the same synchronization problem with the transient-cache as well.

Now the question is, how are these customization items related to the Portlets, Portlet Templates, and Portlet Instances that define them? In the model above this is done with a Configuration. The Configuration has an ordered list of CustomizationFragments where each Fragment has some subset of the customization items for a portlet.
The "ordering" concept in the Configuration allows us to compute exactly what customization item values will be in effect for a given PortletInstance by considering the override attribute of each DataItemInfo and the order in which the fragments are overlaid.