[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp][interfaces]: Portal Usage Scenario
One important thing to also note in this context is that a portlet service may have opaque, internal state that is associated with its instance handle and can be manipulated via the portlet's own UI for changing this internal state to allow for plug and play. Thus, a customization needs not necessarily be represented as externalized properties, it just might be internbal, opaque state of a portlet service. If external properties have to be set by the consumer, you have no plug and play, since the portal side would be required to generate a UI for manipulating the properties. Best regards, Thomas Thomas Schaeck Architect, WebSphere Portal Server IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: schaeck@de.ibm.com Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany Dave Clegg <davec@sybase.com> on 04/16/2002 11:53:15 PM Please respond to Dave Clegg <davec@sybase.com> To: Michael Freedman <Michael.Freedman@oracle.com> cc: Thomas Schaeck/Germany/IBM@IBMDE, Eilon Reshef <eilon.reshef@webcollage.com>, "'Gil Tayar'" <Gil.Tayar@webcollage.com>, "'Sasha Aickin'" <AlexanderA@plumtree.com>, wsrp@lists.oasis-open.org 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 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. (Embedded image moved to file: pic01615.pcx)
Attachment:
pic01615.pcx
Description: Binary data
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC