[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp-interfaces] Groups - Consumer_Defined_Hierarchies.htm (formerly CCPRelationships.htm) modified
Config state changes would only be an explicit setting of state in the 'config mode'. I know that the end user can change end-user state during any interaction with the portlet, but I was trying to draw a parallel to the case when end-user state is explicitly set in the edit mode. thanks, Christopher -----Original Message----- From: Subbu Allamaraju [mailto:subbu@bea.com] Sent: Thursday, July 22, 2004 10:10 AM Cc: interfaces Subject: Re: [wsrp-interfaces] Groups - Consumer_Defined_Hierarchies.htm (formerly CCPRelationships.htm) modified Coco, Christopher wrote: > Yes the edit mode is not required. I don't think thats the point. The > point is, if the edit mode is supported, its purpose is for configuration > of the portlet. No? Even if the edit mode is supported, the portlet can do anything. We have some suggestions in the spec, but don't require that edit mode to be used for state changes. Subbu > > Christopher > > -----Original Message----- > From: Subbu Allamaraju [mailto:subbu@bea.com] > Sent: Thursday, July 22, 2004 10:06 AM > To: interfaces > Subject: Re: [wsrp-interfaces] Groups - Consumer_Defined_Hierarchies.htm > (formerly CCPRelationships.htm) modified > > > Christopher, > > The spec does not require portlets to offer a UI for editing state in > the edit mode, so the consumer cannot expect that. I think that's the > point Yossi was trying to make as well. > > Subbu > > Coco, Christopher wrote: > > > 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:yossi.tamari@sap.com] > > 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: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. > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]