RE: [wsrp-interfaces] Groups - Consumer_Defined_Hierarchies.htm (formerly CCPRelationships.htm) modified

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

Hi Christopher,

While I agree with the general direction you are suggesting, it is true that a portlet can change its (persistent) state as a result of any interaction, regardless of the mode. The modes (like the window states) are really more of UI concepts, where edit mode is expected to be a UI for "configuring/personalizing" a portlet, but not necessarily the only time when that can be done.

	Yossi. 

-----Original Message-----
From: Coco, Christopher [mailto:Christopher.Coco@vignette.com] 
Sent: Thursday, July 22, 2004 7:43 PM
To: Subbu Allamaraju; wsrp-interfaces@lists.oasis-open.org
Subject: RE: [wsrp-interfaces] Groups - Consumer_Defined_Hierarchies.htm (formerly CCPRelationships.htm) modified

Its more a question of portlet state than portlet properties. When parent state
is updated for a portlet with 'child' clones, how are those changes propagated
to the clones, if at all?

The idea behind the 'config' mode is that a consumer needs a mode in which
it knows that it should send a 'shared' state (config state for lack of a
better term) to the producer (for consumer-stored state), or a way for the
producer to know to access the 'shared' (config state) (for producer-stored
state).

I'm not sure what you mean when you say that a consumer cannot assume that
it can use a given mode to edit a portlet's properties. I would disagree
with this statement. What is the point of the current edit mode? Section
6.8.2 in the spec specifically says that this mode is for an end-user to
customize the portlet state.

As to what properties are config versus edit, its completely up to the
Producer, as the state is opaque to the consumer. I don't think we 
have to try to provide a mechanism for this. Yet, only a way to allow
the consumer to access config state of a portlet versus only end-user
edit state. Where config state again is state that is either inherited
from a parent portlet, or passed to a child.

Christopher

Christopher Coco
Senior Software Engineer
Vignette Builder
p. 415.995.3534 | f. 415.975.9801

Vignette's software and expertise help organizations harness 
the power of information and the Web to deliver measurable 
improvements in business efficiency. Vignette is the efficiency 
expert. Visit http://www.vignette.com/ to learn more. 



-----Original Message-----
From: Subbu Allamaraju [mailto:subbu@bea.com]
Sent: Thursday, July 22, 2004 7:01 AM
To: wsrp-interfaces@lists.oasis-open.org
Subject: Re: [wsrp-interfaces] Groups - Consumer_Defined_Hierarchies.htm
(formerly CCPRelationships.htm) modified


Since portlets can modify properties in any mode and are not limited to 
edit/config mode, can you elaborate on why it is important to 
standardize a new mode called config?

Moreover, the consumer cannot assume that it can use a given mode (with 
getMarkup and pbia) to edit portlet's properties.

I remember we had some long debate in the JSR168 EG, and dropped it for 
lack of sufficient motivation.

Subbu

scott.goldstein@vignette.com wrote:

> Information about the document Consumer_Defined_Hierarchies.htm 
> (formerly CCPRelationships.htm) has been modified by Scott Goldstein 
> (scott.goldstein@vignette.com).
> 
> Document Description:
> First draft of feature proposal for Consumer Defined Hierarchies
> 
> Download Document: 
> http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/download.php/7862/Consumer_Defined_Hierarchies.htm 
> 
> 
> View Document Details:
> http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/document.php?document_id=7862 
> 
> 
> 
> PLEASE NOTE:  If the above links do not work for you, your email 
> application
> may be breaking the link into two pieces.  You may be able to copy and 
> paste
> the entire link address into the address field of your web browser.
> 
>