wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] CloneBeforeWrite
- From: Rich Thompson <richt2@us.ibm.com>
- To: "'OASIS WSRP TC'" <wsrp@lists.oasis-open.org>
- Date: Mon, 9 Jan 2006 15:34:38 -0500
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"
<mike@netunitysoftware.com>
01/09/06 02:13 PM
|
To
| "'OASIS WSRP TC'" <wsrp@lists.oasis-open.org>
|
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]