Rich,
I think this clears things up for me. I think the
primmer could be changed a little to reflect it life cycle a little better.
I am still somewhat concerned about the unnecessary cloning
taking place but as you say it is bounded.
Thanks
Mike
From: Rich Thompson [mailto:]
Sent: Monday, January 09, 2006 3:35 PM
To: 'OASIS WSRP
TC'
Subject: Re: [wsrp] CloneBeforeWrite
The concept behind the
portletStateChange field is providing each of the two parties the control they
need to be able to exert:
Consumer: Only the Consumer knows if it is sharing the
portletHandle among multiple users, regardless of whether the portletHandle is a
Producer Offered Portlet handle or a previous clone. Whenever this is true (it
is always true for POPs), the Consumer has the choice of allowing user
customizations (cloneBeforeWrite) or not (readOnly, unless the Consumer wants
the user to be able to customize the portlet for the whole group).
Producer: When a portlet
tries to write to a customization value, the Producer should look at the
portletStateChange flag to determine how to proceed:
readOnly -> fail the attempt to write the
customization value
readWrite
-> allow the write to update the customization value
cloneBeforeWrite -> generate a cloned
portletHandle, apply the update to this new handle and ensure it gets returned
to the Consumer
I would note that
the above means that a new portletHandle should only be returned if the Consumer
said "cloneBeforeWrite" AND the Portlet updated a customization value. There may
be Producers who are unable to insert the right logic in the code path for
updating a customization value. For those Producers, I would expect them to
produce a clone when starting to process a request specifying
"cloneBeforeWrite". This results in unnecessary clones, but once they are not
shared, the Consumer should start specifying "readWrite" ... so at least it is a
bounded problem.
Rich
"Mike Caffyn"
<>
01/09/06 02:13 PM
To
"'OASIS WSRP TC'"
<>
cc
Subject
[wsrp]
CloneBeforeWrite
Some clarification on the use of CloneBeforeWrite.
In the Primmer it looks like
the CloneBeforeWrite is only valid on offered handles. Is this true? If you look
at 6.1.2 Portlet Lifecycle (figure 5) it shows what seems to be only the portlet
management interface can clone a clone. Can consumers call CloneBeforeWrite on
already cloned handles? If so should a new handle be returned or is there any
circumstance that the same handle could be returned.
I have seen a number different
implementations treating the cloning in different ways. Is there a consensus on
how cloning should occur.
Thanks
-Mike
--------------------------------------------------------------------- To
unsubscribe from this mail list, you must leave the OASIS TC that generates this
mail. You may a link to this group and all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
