OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[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