[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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:Scott.Goldstein@vignette.com] 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:andre.kramer@eu.citrix.com] 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: 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:andre.kramer@eu.citrix.com] 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, -----Original Message----- I think that's the way JSR168 tried to define this
mode. However, is Here is an example. Assume that a CCP1 and CCP2 are
cloned from CC0, and In this case, both the hierarchies and configuration
are not exposed in Extending this argument further, I think such
configuration belongs to Christopher, could you elaborate on the motivation (or
specific issues Regards, Subbu Richard Jacob wrote: > |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]