[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp][interfaces]: Portal Usage Scenario
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