OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

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
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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC