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:]
Sent: Tuesday, April 09, 2002
12:06 AM
To: Tamari, Yossi
Cc:
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:]
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-
