[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp][interfaces] separate administration interface
Alejandro, what do you mean with ''but for administration tasks the portlet would have to be aware of the configuration data model of the producer" ? ----------------------------------- Note: This is not a WSRP thought, it is about the Java Portlet API I'd assume the configuration data of a portlet that is affected by the portlet's administration belongs to the portlet, not to the producer. All that should be required to achieve that is to define a standard API to allow portlets to store/get back their configuration data (just like for the instance data) Then the concept of an admin mode in a portlet should work fine, since the portlet has control over its admin mode and its configuration data model on which the admin mode operates. ----------------------------------- If you determine some data based on user roles in your portal implementation, then this data maybe doesn't need to be part of template / entity data itself - this seems more related to user profile / session and. Since the roles of a user can change over time - potentially even within a session - it seems the default values chosen for the instance would not be appropriate anymore after a role change... Best regards, Thomas Jeff Broberg <jbroberg@silverstream.com> on 06/04/2002 06:20:40 AM Please respond to jbroberg@silverstream.com To: Alejandro Abdelnur <alejandro.abdelnur@sun.com>, Angel Luis Diaz/Watson/IBM@IBMUS cc: wsrp@lists.oasis-open.org Subject: RE: [wsrp][interfaces] separate administration interface -----Original Message----- From: Alejandro Abdelnur [mailto:alejandro.abdelnur@sun.com] Sent: Monday, June 03, 2002 10:35 PM To: Angel Luis Diaz Cc: wsrp@lists.oasis-open.org Subject: Re: [wsrp][interfaces] separate administration interface Angel, Assuming that you have a common API to code portlets, then you'll be able to deploy these portlets in any producer that support this common API. Then, a portlet could execute all the regular user functions run in any compliant producer, but for administration tasks the portlet would have to be aware of the configuration data model of the producer. Unless all these producers share a similar configuration data model for storing configuration, a portlet would only be able to do administration in the producer it has been coded against (or another with a similar configuration data model). [Jeff Broberg] Maybe we should define some sort of common mechanism for the configuration data model, or specify an interface that defines the abstract operations. As an example of a different configuration data model than then one being used used (templates) during the WSRP-TC discussions consider the following: When a user selects a portlet and an instance is created the initial configuration values for the portlet are taken from default values associated with organization roles that are merged into a default set. So based on the user roles the default values will be synthesized. [Jeff Broberg] are you suggesting roles should have associated attributes ( key/value pairs ) ? Regards. Alejandro Angel Luis Diaz wrote: I have other concerns regarding portability of portlets across portlet containers but this is outside of the scope of WSRP. I am curious! What are those concerns? Best regards, Angel Angel Luis Diaz, Ph.D Senior Manager, Next Generation eXperience Frameworks IBM T. J. Watson Research Centeraldiaz@us.ibm.com(914) 784-7388 / (914) 441-7594 Alejandro Abdelnur <alejandro.abdelnur@sun.com> on 06/03/2002 01:22:49 PM To: jbroberg@silverstream.comcc: wsrp@lists.oasis-open.orgSubject: 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC