[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp-interop] Hierarchy of CCPs?
|
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] 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. 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]