Just to be sure we see eye to eye: A user can change the edit state in any portlet "screen". The recommended way to display a UI that is only for changing the edit state is using the edit mode.
Yossi.
-----Original Message-----
From: Coco, Christopher [mailto:]
Sent: Thursday, July 22, 2004 8:01 PM
To: Tamari, Yossi; interfaces
Subject: RE: [wsrp-interfaces] Groups - Consumer_Defined_Hierarchies.htm (formerly CCPRelationships.htm) modified
True, the state of a Portlet can change at any point. What I was trying to get at is
the edit mode is where edit state can be explicitly set by an end-user. And similarily,
a config mode would be where config state can be explicitly set by an admin (per se).
Christopher
-----Original Message-----
From: Tamari, Yossi [mailto:]
Sent: Thursday, July 22, 2004 9:57 AM
To: interfaces
Subject: RE: [wsrp-interfaces] Groups - Consumer_Defined_Hierarchies.htm
(formerly CCPRelationships.htm) modified
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:]
Sent: Thursday, July 22, 2004 7:43 PM
To: Subbu Allamaraju;
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:]
Sent: Thursday, July 22, 2004 7:01 AM
To:
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
wrote:
> Information about the document Consumer_Defined_Hierarchies.htm
> (formerly CCPRelationships.htm) has been modified by Scott Goldstein
> ().
>
> 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.
>
>
