[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp][interfaces]: Portal Usage Scenario
Good points! This is exactly the discussion I was hoping we could begin to have. I.e. first develop/describe a list of operations, second identify
whether we want to include the operation in the 1st revision, a later revision, or never. You bring up an interesting alternative to these three
choices, namely define a layered spec where a portlet can choose to implement to a specific level. Would you mind if we hold off on introducing this
possibility into the equation for the moment? I worry that it will make doing the simple categorization harder. Do you think it would work as a two
step process? I.e. first identify according to my classification (this revision, a later revision, never). And then once we haev this list go back
over the "this revision" operations and try and break them into API levels?
-Mike-
Carsten Leue wrote:
> Mike - I have some concerns regarding the number of different instance
> types. At the moment we distinguish between a porltet template and a
> portlet instance. From my understanding the template is primarily used on
> the aggragator's side to allow design time modifications to the portlet's
> settings. As a usecase I imagine a portal that provides a design mode, and
> displays the template e.g. in a tool palette. The designer selects it,
> modifies its settings and make this new "configured instance" available to
> the portal's users who may put it on their pages.
> I think that such a feature is very useful and nice-to-have but maybe not
> required to allow the integration of remote portlets. My concern is that by
> addng to many bells and whistles to the protocoll it will become to
> complicated and hard to use. Why not make this an option? I could imagin
> the following flow (I omit the creation of a binding for clarity):
>
> 1. WSRP interface
> - String crearteInstance(String classID);
> - void destroyInstance(String hInstance);
> - markup and action handling
> the classID specifies the type of portlet to create (e.g. weather portlet,
> stocks quote portlet, etc.). The syntax of this identifier is private to
> the service, values are published to UDDI.
>
> A simple server and client communication:
> String hInstance = createInstance(PORTLET_ID);
> getMarkup(hInstance);
> destroyInstance(hInstance);
>
> If a server wants to support template it could make use of the extended
> interface WSRPDesigner:
> - String createTemplate(String classID);
>
> Such a communication could read
> String hTemplate = createTemplate(PORTLET_ID);
>
> // let the user configure the template
> String hInstance = createInstance(hTemplate);
> getMarkup(hInstance);
> destroyInstance(hInstance);
>
> destroyInstance(hTemplate);
>
> The idea is that the creation of the portlet instance works the same for
> template and non-template modes. It does not require that a template has
> been generated beforehand, but allows for it. Servers that allow template
> generation accept both a class identifier and a template handle as a
> parameter to the createInstance call and perform the approprate action.
> Servers that do not allow for templates simply do not expose the
> WSRPDesigner interface.
>
> From my point of view we should try to keep the base functionality as
> simple as possible to not impose to much implementation effort for both
> clients and servers.
>
> Best regards
> Carsten Leue
>
> -------
> Dr. Carsten Leue
> Dept.8288, IBM Laboratory Böblingen , Germany
> Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
>
> |---------+----------------------------->
> | | Michael Freedman |
> | | <Michael.Freedman@|
> | | oracle.com> |
> | | |
> | | 04/08/2002 11:05 |
> | | PM |
> | | Please respond to |
> | | Michael Freedman |
> | | |
> |---------+----------------------------->
> >---------------------------------------------------------------------------------------------------------------------------------------------|
> | |
> | To: "Tamari, Yossi" <yossi.tamari@sapportals.com> |
> | cc: wsrp@lists.oasis-open.org |
> | Subject: Re: [wsrp][interfaces]: Portal Usage Scenario |
> | |
> | |
> >---------------------------------------------------------------------------------------------------------------------------------------------|
>
> Good questions.
>
> 1. What I meant when I said that personalization data can be shared between
> multiple instances is that the personalization can be shared between
> multiple portlet instances of the same type. For example I can have two
> instances of a Stock portlet that share the same personalization data. In
> this case both instances display the same result. When either is
> customized, the changes are reflected in both as the personalization data
> is shared. This generalization allows a consumer to expose the same
> portlet (result) from different levels in its structure. Remember, a
> portlet instance is defined as a particular reference in the structure
> (portlet on a page). If you want the same content in two locations in the
> structure you need the function defined here. One use of this is in a
> portal that supports access from multiple devices. One can envision the
> need to allow portal designers/users to maintain different portal
> structures between the device (types). However, in such a world the end
> user still wants access to the same content. Cloning is an operation that
> can be used create a second portlet instance with the characteristics that
> its personalization data is shared. So a cloned instance is one that has
> the characteristics described above.
>
> 2. Yes, requesting a portlet instance to render a link reference to
> itself does mean you ask the portlet to render an URL that returns its
> content as markup. I agree that this operation can often be defined by
> meta-data. However it may not always be static. In both this case and the
> case we need to render a title bar for the portlet we must allow a way for
> the portal (consumer) to acquire the portlet's (producers) title. This is
> because the title is commonly personalizable -- hence dynamic. Further
> discussions will resolve whether this occurs during a render operation (get
> "Link") or is merely a getTitle API that returns a string. Done in the
> former the portlet gets an opportunity to define/override the standard
> getContent URL -- hence I included it in the list.
>
> 3. Whether changes to a portlet template's settings should affect existing
> instances is a good question. We should discuss this in the next phase. I
> will add it to the questions list in this area. I will also remove the
> statement from the document (so it can be added once answered). I agree
> there are basic configuration settings that should be propagated. An
> example would be a news feed portlet that requires the URL of the source be
> entered to wire the portlet to a particular news feed. If this URL changes
> there needs to be a way for the update to alter existing instances. On the
> flip side, one can also envision some template settings being the initial
> personalization for an end user. Its not as clear if these values should
> be propogated particularly if there is support for > 1 level of
> personalization in the instance.
>
> Hope this helps.
> -Mike-
>
> "Tamari, Yossi" wrote:
> Hi Mike,I need some clarifications:1. personalization data - What
> does it mean that it can be shared between multiple instances? do you
> mean instances of the same portlet? if so, why is that a different
> instances, i.e. why should the consumer request the exact same data
> twice? And how is that different from a cloned instance?2. "You can
> request a portlet instance render a link reference to itself" - Does
> that mean you ask the portlet for a URL that returns its content as
> markup? I think this should be part of the meta-data, as it does not
> need to be truly dynamic.3. Why should changes to the portlet
> template's settings not affect existing instances? If the name of my
> company was change, I want the new name rendered in ALL the
> instances. Yossi.
> -----Original Message-----
> From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
> Sent: Saturday, April 06, 2002 9:53 PM
> To: WSRP
> Subject: [wsrp][interfaces]: Portal Usage Scenario
>
> I have attached a short document describing a portal's possible
> usage pattern for portlets using the terms we discussed last
> week. Please comment/annotate with new operations or suggested
> operations to remove. Please don't annotate with questions
> intended to clarify the behavior of the operation, send these
> separately. The goal for this Thursday's meeting is to see if
> we can agree on a preliminary usage pattern and collection of
> operations. Hopefully we can then move into enumerating the
> questions we need to answer. In our discussion on Thursday, I
> expect we will need to classify at least the operational
> aspects of the usage scenario along two axes:
>
> Axis 1: Is this a valid Portal operation?
> Yes, we all agree this a valid operation
> No, we all agree this is not a valid operation
> Maybe, there is debate whether this is a valid operation.
> Don't know, we need more information and discussion to
> understand the operation before classifying it.
>
> Axis 2: Should this operation be covered/enabled by our spec?
> Yes, we all agree.
> Yes, but it should be addressed in a later revision.
> No, we all agree.
> Maybe, there is debate whether we should address this.
> Don't know, we need more information to decide.
> It might be useful if each of you did your own classification
> (assuming of course the usage scenario isn't grossly
> controversial).
>
> -Mike-
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC