RE: [wsrp][interfaces]: Portal Usage Scenario

["Tamari, Yossi" <yossi.tamari@sapportals.com>]

Hi Thomas,

I don't think that the fact the portal can set the portlet's properties
means that there can be no plug-and-play.
The Portlet can advertise its properties and their type (XML-Schema like) in
its meta-data, and the portal can use this meta-data to automatically
display a set-properties page. While this page can not be as customized as
the portlet generated page, it has the advantage of creating a uniform
set-properties look and feel throughout the portal.

I'm just saying both options have their merits, and we should regard both.

	Yossi.

-----Original Message-----
From: Thomas Schaeck [mailto:SCHAECK@de.ibm.com]
Sent: Wednesday, May 15, 2002 10:35 PM
To: Dave Clegg
Cc: Michael Freedman; Eilon Reshef; 'Gil Tayar'; 'Sasha Aickin';
wsrp@lists.oasis-open.org
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)