RE: [wsrp][interfaces] separate administration interface

[Thomas Schaeck <SCHAECK@de.ibm.com>]

I think a reasonable approach would be this:

1. For portlets that provide an edit mode at the template level,
administrators can use the portlet service's UI to modify a portlet
template
-> Portals can very easily allow their administrators to modify portlet
tempates of such advanced portlet services by just integrating the portlet
services's admin UI (I think this is the preferrable approach, since the
portlet service itself knows best how the UI for modifying its own
templates should look like).

2. For portlets that do not provide an edit mode at the template level
themselves but only expose certain String properties, portals could
generate a UI heuristically based on the properties.
-> Portals (to a certain extent) can also allow their administrators to
modify portlet templates of such primitive portlet services by doing the
presentation for the admin UI as good as possible and modifying the
appropriate properties.

Option 2 has limitations, but may be sufficient for simple services, like
for portlets that only have simple properties as template data (e.g. "Stock
Quote Source URL").
An example for which the portal certainly won't be able to generate the UI
would be a clipping portlet that lets the administrator enter and clip a
URL visually, storing a clipping definition in XML as the portlet template
data, or a Map Portlet that lets the administrator preset a default
location for portal templates by zooming into a world map.

Portlet services that have template data that can be completely exposed as
portlet template properties might offer both options, however for an
advanced case like the clipping portlet an auto-generated UI based on
properties would hardly work. For such cases I guess the only option is
that the portlet service itself provides the UI for modifying portlet
templates.

Alejandro, I am not aware of a reason why an administrator would have to
put a portlet template on a page to edit the template - I think a typical
representation of portlet templates in a portal would be the list of
"portlets" that users can pick in a portal's customizer / toolbox / ... For
administrators, the portal could offer UIs like "Work with portlet
templates" that lets them see the list of templates they have created,
create new ones, delete portlet templates and of course click on portlet
templates to launch the edit mode on the portlet template level.

The edit mode at the template level corresponds to a "CONFIGURE" or "EDIT
TEMPLATE" mode for local portlets so that local Java Portlet API and WSRP
will fit very nicely together if we do these things right ...

Best regards,

Thomas



Jeff Broberg <jbroberg@silverstream.com> on 06/03/2002 07:37:09 PM

Please respond to jbroberg@silverstream.com

To:    Alejandro Abdelnur <alejandro.abdelnur@sun.com>
cc:    wsrp@lists.oasis-open.org
Subject:    RE: [wsrp][interfaces] separate administration interface




Thanks  for the clarification.  I understand your concerns regarding the
need to  portal to do the administration, but i also see many benefits to
this.  Are you suggesting that the "administration" portion of a portlet be
exposed in its metadata so that the consumer can construct an editor that
is  used within the consumers context, which would allow customization to
the  portlet template ?

-----Original Message-----
From: Alejandro Abdelnur  [mailto:alejandro.abdelnur@sun.com]
Sent: Monday, June 03, 2002 1:23  PM
To: jbroberg@silverstream.com
Cc:  wsrp@lists.oasis-open.org
Subject: Re: [wsrp][interfaces] separate  administration interface


Jeff,

In both cases,  Personalization and Administration, I'm referring to the
customization and  personalization capabilities that a portlet exposes.

As it has been  discussed so far, Administration is just a special case of
Personalization  where the user, because he/she has an administrator role,
can set  configuration data at template level and because of his/her role
can see/touch  more configuration parameters.

I see Personalization done through the  portlet (i.e.: when the user clicks
the EDIT button) as the user has the  portlet in his/her portal page.  The
portlet itself knows how to persist  the configuration data that is meant
for a specific user, the one making the  customization. Based on the user's
roles more or less configuration parameters  are exposed to the user.

The main problems I see by doing  Administration in the same way as
Personalization are:

* An  administrator has to set the portlet template in a portal page in
order to  configure it.
* There is no provision, neither metadata, to enable  administration
through other means such as a command line tool or a  configuration
console. The Administration has to be done exclusively through  the portal.

I'll prepare a list of requirements on this matter and I'll  send it to the
alias.

I have other concerns regarding portability of  portlets across portlet
containers but this is outside of the scope of  WSRP.

Regards.

Alejandro



Jeff Broberg wrote:

I am alittle confused.  If a portlet wanted to expose some administration
capabilities such as allowing parameters to be modified for
personallization
wouldnt they expose an "Administration" action that would then be shown to
the appropriate users based on their roles.  Or is the type of
administration that you are talking about different from the
customization/personalization capabilities that a portlet exposes ?

jeff

-----Original Message-----
From: Alejandro Abdelnur [mailto:alejandro.abdelnur@sun.com]
Sent: Thursday, May 30, 2002 7:58 PM
To: wsrp@lists.oasis-open.orgSubject: [wsrp][interfaces] separate
administration interface



I have some concerns on the idea of using the usage interface for doing
administration tasks on a portlet.

I think we should have a separate administration interface. And,
probably, some metadata (provided by the portlet) describing how the
portlet should be administered.

I'm re-posting a message I've sent last week, as it was a reply to
another email, because of the subject, some of you may have overlooked
it. Mike and Eilon replied to it, so you may want to check the thread in
the archives.

Thanks and regards.

Alejandro

-------- Original Message --------
Subject: Re: [wsrp][interfaces]: Portal Usage Scenario
Date: Tue, 21 May 2002 16:57:54 -0700
From: Alejandro Abdelnur <alejandro.abdelnur@Sun.COM>Organization: Sun
Microsystems, Inc
To: "Tamari, Yossi" <yossi.tamari@sapportals.com>CC: "'Thomas Schaeck'"
<SCHAECK@de.ibm.com>, wsrp@lists.oasis-open.orgReferences:
<5199D0E7CA63D511BB6F0008C75DAD1403653228@dbwdfx2e.wdf.sap-ag.de>Tamari,
Yossi wrote:



Hi Thomas,

I don't think that the fact the portal can set the portlet's properties
means that there can be no plug-and-play.
The Portlet can advertise its properties and their type (XML-Schema like)


in


its meta-data, and the portal can use this meta-data to automatically
display a set-properties page. While this page can not be as customized as
the portlet generated page, it has the advantage of creating a uniform
set-properties look and feel throughout the portal.

I'm just saying both options have their merits, and we should regard both.

      Yossi.




I agree with Yossi. We should investigate/consider other alternatives.

This is somehow related to an issue I've brought up in the WSRP/security
conf call last week about "...separation of interfaces and roles for
administrative vs. non-administrative usage. ..."

I see some key problems on the approach we are heading to, where we do
not have a separate administration interface from the regular usage
interface. Administration and personalization are very different beasts.

Using a definition from a colleague, personalization of a component is
when a user customizes the behavior of the component for himself; while
administration is when a user customizes the behavior of the component
for one (other than her) or more users.

I see personalization being done through the usage interface, as most
portal frameworks -if not all- do it today.

I see as a possibility to do administration of portlets through
portlets, not the same portlet but a special administration portlet
provided by the WSRP service.

I have problems seeing administration functionality being done through
the usage interface of the same portlet is to be administered.

Personalization is about a given portlet instance for a given user.
Administration may have to deal with roles, groups, templates, etc.

In my opinion, it will be very hard to implement a portlet to do this
administration unless the portlet is knowledgeable of the WSRP service
configuration data model. A portlet knows about the business logic it
produces presentation logic for. A portlet knows about the
configuration/personalization parameters it needs. But a portlet does
not necessary know how the container hosting the portlet organizes and
stores the configuration or personalization parameters handled to the
portlets.

Another problems that I see are:

* The administration interface should allow an administration tool to be
built using portlets, but it must not impose additional requirements on
the administration framework.

* Administration should not require the administrator to put the portlet
in his portal page in order to administer it.

* It should be the responsibility of the WSRP service (or the portal),
but not of the portlet, to manage the details of delegated administration.

* Security of the usage and administration interface may be different.

* It's delegated to the portlet to decide if a user can do
administration or not.

* The usage interface may have different scalability requirements than
the administration interface.

Finally, there are different specifications that address management of
resources in distributed environments such as CIM, SMNP, JMX (Java
specific). Also, in OASIS there is a proposal for a Management Services
TC. We should investigate if any of them are suitable.


Regards.

Alejandro




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>