Re: [wsrp][interfaces]: Portal Usage Scenario

[Thomas Schaeck <SCHAECK@de.ibm.com>]

Mike,

I think to enable dynamic titles, we could define an optional field in the
WSRP markup response that may provide the current title to be displayed,
similarly to begin/end page fields that may optionally complement the
portlet "body" markup itself.

Such an optional title field would nicely correspond to doTitle() method in
the Portlet API that portlets optionally may implement.

The behaviour should be that if a dynamic title comes with the response,
the portal should display it, if no dynamic title comes with the response,
the portal should default to displaying the static title from the metadata.

Best regards,

Thomas

Thomas Schaeck
Architect, WebSphere Portal Server
IBM Pervasive Computing Division
Phone: +49-(0)7031-16-3479   Mobile: +49-(0)171-6928407   e-mail:
schaeck@de.ibm.com   Fax: +49-(0)7031-16-4888
Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032
Boeblingen, Germany


Michael Freedman <Michael.Freedman@oracle.com> on 04/10/2002 10:52:09 PM

Please respond to Michael Freedman <Michael.Freedman@oracle.com>

To:    "Tamari, Yossi" <yossi.tamari@sapportals.com>
cc:    wsrp@lists.oasis-open.org
Subject:    Re: [wsrp][interfaces]: Portal Usage Scenario



Yossi,
 1) A clone and/or copy operation is relevant to WSRP (portlets) if the
portlet maintains the personalization data.  In this situation a copy or
clone operation must be indicated to the portlet so it can properly manage
the data. I can think of a number of situations where copy/clone might come
into play besides the example I gave.  One is  the "publish" operation
Thomas discussed in a later e-mail.  Another is a copy page function within
a portal -- where a developer wants to start a new page using the initial
structure/content of an existing page.

As this all boils down to who maintains the personalization data I have
made sure its added to the questions list.  Personally, I agree with Thomas
on this issue.  I personally believe that the default mechanism is that
personalization data is managed by the portlet.  We will allow (but not
require) portals to provide a personalization storage service whereby the
information can be managed at the portal.  A portlet will decide at bind
time how it wants its data managed.  It will be valid for a portlet to only
work in an environment where the portal manages the personalization data.
The bind/negotiation operation will fail when such a portlet is being bound
into a portal that doesn't support this.  Note:  though there are other
permutations of the default behavior, I am wary of any design that mandates
the portal provide this service.  My goal is to leave portal vendors
flexibility to build their function as they seem fit (or at least give them
longer to adapt their systems) and focus on defining the necessary
interactions between the two.  Of course all of this is up for discussion.
But before this can begin we need to identify the operations to model and
the issues/questions surrounding them.  That is the phase we are in now.

2) Yes, meta-data can/should be used so that the roundtrip can be avoided.
Again my focus at the moment is capturing the list of useful operations.
We still need to discuss whether to include this operation in revision 1, a
future revision, or never.

As for its performance, as its a simpler form of the getmarkup call,
rendering in Link mode should be faster then rendering in full display
mode.  And that is of course discounting any benefits gained from caching.

     -Mike-

"Tamari, Yossi" wrote:  Thanks for the answers, but I'm still not satisfied
on 1 and 2...1. What bothers me here is that the fact the same portlet
instance appears in different places in the portal structure is completely
handled by the portal. The producer does not know/care where this instance
is in the portal pages. Hence while the feature is logical in the portal
framework, I don't see its relevance to WSRP.2. I see your point, I'm just
worried about performance. We should give this some more thought. Maybe the
metadata could either give a URL\title or say that it is dynamic.    Yossi.
-----Original Message-----
From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: Tuesday, April 09, 2002 12:06 AM
To: Tamari, Yossi
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-