OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interfaces message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrp-interfaces] Groups - Consumer_Defined_Hierarchies.htm (formerlyCCPRelationships.htm) modified


I think that's the way JSR168 tried to define this mode. However, is 
there a reason to think that such configuration cannot be addressed by 
the current portlet management interface?

Here is an example. Assume that a CCP1 and CCP2 are cloned from CC0, and 
CCP1 and CCP2 are hierarchically related to CC0 (the relationship is 
producer-implementation specific and is not exposed in the protocol). To 
configure this portlet, the admin sends setPortletProperties request for 
CC0, where as users send setPortletProperties request for CCP1 and CCP2. 
The producer, in some implementation specific way, propagates data 
changes from CCP0 to CCP1 and CCP2.

In this case, both the hierarchies and configuration are not exposed in 
the protocol. Here, I considered the parent to be a CCP to be consistent 
with the current setPortlteProperties operation.

Extending this argument further, I think such configuration belongs to 
the portlet maangement interface and not the markup interface. With 
markup interface, a consumer can allow/disallow a producer/portlet to 
change its state, but cannot force persistent state changes. The portlet 
management interface, on the otherhand, allows for *explicit* state changes.

Christopher, could you elaborate on the motivation (or specific issues 
faced in implementation) for exposing hierarchies in the protocol?

Regards,

Subbu

Richard Jacob wrote:

> 
> 
> 
> 
> I think what is discussed in the thread is basically the question if there
> is some kind of "shared" state which applies to all portlets (of the same
> class, i.e. are cloned from the same POP) - Chris named it "config" state.
> If I understood correctly the proposal could be to have one area of the
> portlet state which has the explicit notion of configuration data in
> contrast to the customization data.
> One example:
> A mail portlet could have configuration data like the smtp and imap server
> FQDNs which can be changed by the admin only (Chris referred to the
> "config" mode here).
> Whereas customization data would be the email address or login name of each
> individual user, i.e. user's could do customization to that (for example in
> the "edit" mode).
> 
> Mit freundlichen Gruessen / best regards,
> 
>         Richard Jacob
> ______________________________________________________
> IBM Lab Boeblingen, Germany
> Dept.8288, WebSphere Portal Server Development
> WSRP Standardization Technical Lead
> Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
> Email: mailto:richard.jacob@de.ibm.com
> 
> 
>                                                                           
>              "Coco,                                                       
>              Christopher"                                                 
>              <Christopher.Coco                                          To
>              @vignette.com>            "Subbu Allamaraju" <subbu@bea.com> 
>                                                                         cc
>              07/22/2004 07:11          "interfaces"                       
>              PM                        <wsrp-interfaces@lists.oasis-open.o
>                                        rg>                                
>                                                                    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]