RE: [wsrp-interop] Hierarchy of CCPs?

["Coco, Christopher" <Christopher.Coco@vignette.com>]

Exactly how would this be possible with opaque state? This would necessitate the
Consumer "knowing" about the state from the Producer. Hence, not opaque. Unless
there is something we're missing?

Christopher

-----Original Message-----
From: Subbu Allamaraju [mailto:subbu@bea.com]
Sent: Thursday, June 24, 2004 10:35 AM
To: wsrp-interop@lists.oasis-open.org
Subject: Re: [wsrp-interop] Hierarchy of CCPs?


As Rich clarified, there is no hierarchy implied in the spec. If 
consumers want to tie CCPs in a hierarchy, they could do so without the 
help of the protocol. May be hard to implement for the Consumer, but 
possible, I think.

Subbu



Goldstein, Scott wrote:

> Thanks for the info.
> 
>  
> 
> I can understand, for EDIT DEFAULTS, not having the user continue to see 
> state changes.  This is the nature of default values.  However, in my 
> mind, this doesn’t necessarily make sense for the CONFIG mode.  Consider 
> the use case of an E-mail portlet.  A reasonable CONFIG mode preference 
> would be the POP server address for the company.  What if the server has 
> moved?  Do you then have to create a new portlet instance and have all 
> users re-customize the end user preferences?  Ideally, you could simply 
> change the preference in CONFIG mode and have it apply automatically to 
> the current portlet instance in use.
> 
>  
> 
> Scott
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Michael Freedman [mailto:Michael.Freedman@oracle.com]
> *Sent:* Thursday, June 24, 2004 9:16 AM
> *To:* wsrp-interop@lists.oasis-open.org
> *Subject:* Re: [wsrp-interop] Hierarchy of CCPs?
> 
>  
> 
> You are correct that the producer can not  retain/assume relationships 
> between portlets.  That is entirely the duty of the consumer.  As for 
> CONFIG/EDIT DEFAULTS modes, JSR 168 doesn't require dynamic inheritence. 
>  I.e. there is no requirement/statement that if a user customizes a 
> configured portlet that that user will continue to see changes made 
> after the fact to the configuration.
>     -Mike-
> 
> Goldstein, Scott wrote:
> 
> Suppose I clone a POP, A, to get a CCP, B.  Also, suppose that I clone 
> the CCP, B, to get a CCP, C.  Is there an inherent hierarchy between B 
> and C?  If so, how does it affect behavior?  For instance, suppose I 
> call destroy with portlet, B.  Does it also destroy C?  I would assume 
> no, since I didn’t see this in the spec.
> 
>  
> 
> However, if B and C are not hierarchical, then how would a producer 
> support JSR 168 CONFIG or EDIT DEFAULTS mode where some state applies to 
> all users of a portlet?  It would seems that you would need the single 
> clone, B, for the shared state, and clones C1…Cn, for user specific state.
> 
>  
> 
> Scott
> 
>  
> 


To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php.