Hi
Mike,
1. I
still don't see why the clone operation is needed. I did not mention the copy
operation. The cloned portlet has the same personalization data as the original
one, so the producer does not care where in the structure it is
placed.
I think I disagree with you as to the default
personalization repository, but as you said this is open to discussion, and I
agree both should be supported.
2. The
performance will be worse, from the end user point of view. It will take the URL
request one round trip to return, but than another round trip is needed
from his browser to actually get the data...
Yossi.
-----Original Message-----
From: Michael Freedman
[mailto:]
Sent: Wednesday, April 10, 2002
11:52 PM
To: Tamari, Yossi
Cc:
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:]
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-
