[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp][interfaces and protocols]: Portal using WSRP Service
1>How
does your two terms "Serialized/Stored Instance" and "Active Instance" differ
from the one's in my document; "Personalization Data" and "Portlet
Instance"? They seem very similar to me.
"Portlet Instance" in your document means - "a portlet on a page; or more generically a portlet in the portal layout structure". If this means a portlet instance is created only when viewed by the end user (i.e. runtime and not design time), then my apologies for failing to understand. I believe my failure to understand came from the list of
operations you designated on portlet instances. For example "You can copy a
portlet instance. By copy it is meant that a second portlet instance comes
into being with its personalization data being a duplicate of the instance it
was copied from". Why does WSRP need such an operation? Instead (In your
terminology), the portal can just create a new instance with the personalization
data used to create the old instance.
Now, I understand why a portal would need to
expose such functionality to the end user (copy/paste of a portal on the page),
but why would WSRP?
2>Also, why do you think its important/required that portal
store/manage the portlets (producers) settings and personalization data?
Isn't there value in allowing these portlets to store/maintain this data
themselves?
Good question (and very much related to the first!). This may be true, but remember that a remote portlet may work with multiple portals (each with a different user base) at the same time. If we require the portlet to store customization preferences, then this puts too much burden on portlet. In the "local" portlet world, the portlet had access to infrastructural code (of the portal) that can store the preferences for the portlet. This structural code was usually code supplied by the portal. In the remote portlet world, the portlet is "alone", and must supply "preference" storage themselves, i.e. a database. Moreover, this information must be synchronized
with the data stored in the portal itself about the portal instance (for
example, the location of the portal instance on the page). So the two must be
synchronized. But this is difficult - what happens when the user deletes the
portal instance from the page - should the portal send a "deleteData" message to
the portlet? What if the portlet is "down" at that time? Now the portal needs to
queue the request.
Another (more conceptual/logical) problem is that (and I
quote from your document) "There are an arbitrary set of personalization levels
defined by the particular portal. The levels are hierarchical. The
deepest personalization level that has any overriding values controls the user's
view" - do we expect the portlet to understand this hierarchy and the rules
governing the overriding and inheritance? If portlet's store the personalization
data, then they must. And if they must, then WSRP must define the hierarchy and
the rules. Do we expect WSRP to standardize these? Seems to me that this is the
domain of the portals, and not of the interface.
I think these two questions all boil down to the second one: who
manages the personalization/customization data - the portal or the
portlet?
Gil
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC