Re: [wsrp-interop] Hierarchy of CCPs?

[Michael Freedman <Michael.Freedman@oracle.com>]

Well, there are tricks you can do if the CONFIG values are distinct from
the EDIT  values -- namely use two WSRP portlets to represent one consumer
instance.  I believe this could be made to work with JSR 168 on top as well.
 Though there would be some limitations relating to portlet session state
as you crossed into/out of CONFIG mode.

Anyway, we chose no the "no relationship" model for simplicity as we weren't
making much headway on defining an expression language so all consumers to
express all relationships.  Some of these basic cases are easy [and easy
to understand] but suffer from the problem that things like CONFIG and EDIT_DEFAULTS
aren't even part of the standard.  Anyway, the biggest proponent for reflecting
relationships was Allan Kropp.  Unfortunately he has moved on and no one
has taken up the ball.  
    -Mike-


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