Next in thread →
Next in month →
RE: [wsrp-interfaces] Groups - Consumer_Defined_Hierarchies.htm (formerlyCCPRelationships.htm) modified
Title: RE: [wsrp-interfaces] Groups - Consumer_Defined_Hierarchies.htm
(formerlyCCPRelationships.htm) modified
Regarding sharing configuration state:
I don’t think it should be part of
the hierarchy/ config discussion. I think the use case for sharing edit state
is much bigger than for config state. After all edit state needs to be
maintained by each user while config state is only set once (typically) by an
administrator, so the extra hassle of having to do it per portlet in an
application is smaller.
In other words, while sharing persistent
state may be useful, I think it is a completely different discussion.
Yossi.
From:
Goldstein, Scott [mailto:]
Sent: Monday, July 26, 2004 9:08
PM
To: Andre Kramer; interfaces
Subject: RE: [wsrp-interfaces]
Groups - Consumer_Defined_Hierarchies.htm (formerlyCCPRelationships.htm)
modified
I see access control of
property modifications being solved through our user identity propagation
mechanisms. The Producer can simply assert the current users role to
determine if they can modify a particular property. Is there a reason
this would not be sufficient?
I do see a use case for
sharing configuration state across portlet boundaries within a portlet
application. I’m not sure, however, that it’s a particular
use case that I would want to solve within this feature proposal. How do
others feel?
Scott
From: Andre
Kramer [mailto:]
Sent: Monday, July 26, 2004 7:34
AM
To: interfaces
Subject: RE: [wsrp-interfaces] Groups -
Consumer_Defined_Hierarchies.htm (formerlyCCPRelationships.htm) modified
On the
config access control suggestion, I was purposely being neutral on what scope
the admin's modifications would have. Hierarchy related changes are already
proposed, but administration "delegation" (i.e. for all users I
manage) and Portlet application scope (i.e. for all users of that application)
seem very valid re-occurring use cases to me.
We have
"groupID"s for supporting JSR 168 in WSRP 1.0 but this still does not
seem well matched to such scopes. At the risk of confounding two 2.0 feature
discussions (sorry): We could leverage registrations and the newHandle =
copyPortlet(portletHandle, fromRegistrationHandle, toRegistrationHandle) to
scope the "sharing" of property modifications. Rather than building
in extra support (formal contracts) for shared customizations, this could
enable shared properties to be updated in a registration (per-Registration -
but never across registrations. And non-shared properties are just
per-Portlet/per-Registration). This does not state how properties are actually
shared within a registration (can have more complex inter-clone relationships
within registrations) or who may update shared properties, but this could
enable some very typical use cases: e.g admin changes settings for a Portlet
application. Here, the consumer would only allow an authenticated/authorized
Admin to effect such (audited) changes. And the fact that only producer admin
is allowed to change POPs is reflected by an implicit top level (default)
scope.
Again,
I'm just thinking aloud, ahead of next week's f2f.
Regards,
Andre
From: Goldstein, Scott
[mailto:]
Sent: 24 July 2004 19:44
To: interfaces
Subject: RE: [wsrp-interfaces] Groups -
Consumer_Defined_Hierarchies.htm (formerlyCCPRelationships.htm) modified
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.
1. 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.
2. 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.
3. 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.
4. 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.
5. 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:]
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:]
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:
>
>
>
>
"Coco,
>
Christopher"
>
<Christopher.Coco
To
>
@vignette.com>
"Subbu Allamaraju" <>
>
cc
>
07/22/2004 07:11 "interfaces"
>
PM
<-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:]
> 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:]
> > 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:]
> > > 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:]
> > > Sent:
Thursday, July 22, 2004 7:43 PM
> > > To:
Subbu Allamaraju;
> > > 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:]
> > > Sent:
Thursday, July 22, 2004 7:01 AM
> > > To:
> > > 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
> > >
> > >
wrote:
> > >
> > >
> Information about the document Consumer_Defined_Hierarchies.htm
> > >
> (formerly CCPRelationships.htm) has been modified by Scott
> Goldstein
> > >
> ().
> > >
>
> > >
> 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.
> > >
>
> > >
>
> > >
> >
>
>
>
Next in thread →
Next in month →