[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp-interop] Hierarchy of CCPs?
It’s possible to use two WSRP
portlets to represent the one instance, but because state is opaque to the
Consumer, it requires producer side persistence and an understanding between
the consumer and producer that the two instances are hierarchical with respect
to portlet state (e.g. one inherits state values from the other). Because
the spec doesn’t dictate this hierarchy, this would have to be a
proprietary solution. I can take ownership of this issue. I
assume that it would be part of the interfaces committee? Scott From: Michael
Freedman [mailto: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. 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]