[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp][interfaces]: Portal Usage Scenario
Can you clarify what you mean by "Administrator"? In our world we have (at least) three levels: a) Administrator b) Page/Portal Designer c) End User Your use of Administrator seems to map closest to our (a) Administrator. [see definitions below]. When others have talked about it I have mapped to (b) Page/Portal Designer. I can see how (a) might be done out of the "usage interface". Its less obvious to me the value to do (b) outside the "usage interface". Definitions: The Administrator is responsible for registering/adding portlets to the portal. The administrator can configure portlets (change those configuration settings that are modifiable). Changes made here effect all portlet instances created here after. The Page/Portal Designer is responsible for developing the initial structure of the portal for a collection of end users. In doing so the Page/Portal Designer is capable of modifying portlet settings. Portlet settings may effect either portlet state or behaviors of a specific portlet instance (though its just as easy to imagine that this instance is a template for future instances). Commonly, these settings include the End user customization attributes allowing the Page/Portal Designer to preset defaults for the End-Users. End User is responsible for personalizing the Portal. In doing so they are capable of personalizing portlets. -Mike- Alejandro Abdelnur wrote: > 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