I’m a little behind in the
discussion, so I’m going to try to cover all comments that I’ve
seen thus far. Let me know if I miss anything.
First, Andre brought up the notion of
portlet properties. The feature proposal, as it stands, talks about
hierarchies in relation to portlet state. This was the use case we had,
and, therefore, that’s what I modeled the feature proposal around.
However, when you start discussing CCP hierarchies, portlet properties and inheritance
of portlet properties is a feature which obviously must be considered. In
order to validate such a feature, we would have to come up with an associated
use case. Personally, I think you can adapt the one I provided for
portlet state fairly easy. The consumer could generate a screen within an
administration view to set portlet properties for a “parent”
CCP. These values could then be inherited to “child”
CCP’s created as a result of additional end user customization of the
portlet. If necessary, the administrator could return to the
administration screen to change the value of the portlet properties on the
parent and affect all of the “child” CCPs due to the
inheritance.
Secondly, Rich brought up the notion of
declaring a portlet property to be final or config level. This involves
the situation in which properties can be set on a particular
“parent” CCP, but not on child “CCPs”. To
understand the use case, I would ask who can determine whether a particular
portlet property should be final or not? To answer this question, I think
you have to consider the following actors – Consumer, Producer, Consumer
Administration, Producer Administration, and Portlet Developer.
- Consumer
– Since a Consumer doesn’t really understand the purpose of a
particular portlet property, it really can’t make a determination
whether a particular portlet property is an administrative one or
not. Therefore, I would suggest that the Consumer isn’t able
to make this determination.
- Consumer
Administrator – In this case, the Consumer would autogenerate a
screen within an administrative context for setting portlet properties on
the “parent” CCP. Within the autogenerated screen, next
to each property, would be a check box to set whether or not end users
could override or customize the value of the property. By selecting
the check box, the portlet property can be set to be final, not allowing
the property to be set on “child” CCPs and, therefore, not allowing
end users to customize it.
- Producer
– I think this is the same case as the Consumer. It
doesn’t understand the purpose of portlet properties and, therefore,
can’t make a determination whether or not a property should be
final.
- Portlet
Developers – When developing a portlet for general consumption, a
portlet developer wouldn’t want to limit functionality. In
other words, the ultimate goal would be to make the portlet as
configurable as possible, allowing it to be reused in multiple
environments with varied requirements for access control. I do imagine
a scenario in which they may want to suggest a default behavior based on
the function of the portlet, but they wouldn’t want to make the
final determination.
- Producer
Administrator – If a particular property affected a back end system
or required knowledge of a back end system, I could see the case in which
you would want, as a Producer Administrator, to limit access to those
properties to admin users only. Therefore, it would make sense that
a Producer Administrator would want to declared properties final.
However, I would argue that it would be difficult to determine on which
CCP to declared the property final. It depends on the Consumer
implementation and how CCPs are used. What you could do, I suppose,
is declare a property to be final within a POP as a suggestion to the
Consumer. However, this really wouldn’t provide any hard
control. The question would be, is there a use case for having the
ability to provide only a suggestion?
Given the above, I can see #2 being a
possible reason for having the ability to set a portlet property to be
final. #5 is also a possibility, but questionable. Rich and Yossi
– You both seems to be interested in this feature. What are your thoughts
on the above? Do you agree? Would your use cases fall into #2 and #5
or is there a scenario that I’m missing?
Thirdly, the question came up as to why
you would want to declare a CONFIG mode within the WSRP specification.
This is related to the difference between portlet state and portlet
properties. In item #2 above, the consumer provides a check box to
declare what properties an end user should be able to edit. It’s
possible, however, for usability reasons, that an autogenerated screen
isn’t ideal for configuring a particular portion of portlet state.
For instance, in the use case I’ve given, the config mode of the portlet
generates an expandable folder tree representing the directory structure of the
content repository. I can’t think of a standard XSD data type which
would lead a consumer to autogenerate such a tree, much less one with the exact
contents of a back end repository. Therefore, it makes more sense for the
portlet to generate the screen and set the state through a pbia().
However, as a portlet developer, ideally you still want to provide the
flexibility to the Consumer Administrator to declare what an end user
should/shouldn’t be able to customize. This is where CONFIG mode
comes in. It would contain a checkbox for configuring whether or not end
users could change the folder. You then have an option of, near the
checkbox, rendering the folder tree allowing the admin to specify a default, or
rendering this tree within another mode which correlates to the jsr 168 EDIT_DEFAULTS
mode.
I would also argue that, due to lack of
time or prior knowledge of the deployment environment (company intranet), a
portlet developer would decide to simply not provide a checkbox. In other
words, they would make the decision that selecting a content repository folder
for the portlet is purely an admin function that end users shouldn’t be
exposed to. They can achieve this, by only displaying the folder tree
within a CONFIG mode.
A final reason would simply be
interoperability with JSR 168 portlets. Considering that JSR 168 is a
large source of the portlets to be produced, it makes sense to try to align as
much as possible with this specification.
Fourthly, Subbu brought up the fact that a
Producer could implement hierarchies on it’s own, without the use of the
protocol. I would argue that this isn’t sufficient. First,
since a Consumer could never know if a producer provides this functionality, it
would never predict when property/state inheritance would occur. Secondly,
I would argue that it’s the Consumer implementation/feature set that
determines if properties/state should be inherited or not. Where one
consumer would desire the inheritance behavior, another might not.
Therefore, you need support in the protocol for the consumer to request that
inheritance be utilized.
Lastly, Andre brought up the notion of
using access control for authorization rather than a config mode. The
issue I see with this, is that config mode is more than simply the properties
which only an admin can see. It also provides a mean of setting portlet
state which applies to all users. It just happens to be the case that, in
most if not all scenarios, the responsibility of setting state for all users is
given to an administrator.
I think that covers all of the comments
which I saw. Some of this information probably need to be rolled into the
use cases in the feature proposal. Before doing that, though, I’ll
wait to see what everyone agrees/disagrees with.
Scott
From: Andre
Kramer [mailto:andre.kramer@eu.citrix.com]
Sent: Friday, July 23, 2004 7:11
AM
To: interfaces
Subject: RE: [wsrp-interfaces]
Groups - Consumer_Defined_Hierarchies.htm (formerlyCCPRelationships.htm)
modified
Just an attempt at an observation: When we think of
this ("config") as a mode it seems never to be very compelling but
when we view it as something an admin does (versus a normal user) we tend to
see a valid use case.
Maybe re-casting this in terms of "access
control" or "authorization" would be an approach? The portlet
would declare and enforce edit authorization based on user / role
authentications. The consumer would need meta-data (WS Policy) in order to also
act as a policy enforcement point.
Here "config" is not so much a mode but a
special role that we recognize?
Regards,
Andre
-----Original Message-----
From: Subbu Allamaraju [mailto:subbu@bea.com]
Sent: 23 July 2004 14:43
To: interfaces
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.
> > >
>
> > >
>
> > >
> >
>
>
>