Title: Message
Makes sense. My only personal
confusion: what would be a concrete scenario where - to Gil's first question -
no user is seeing a portal page and yet a portlet
instance exists?
Eilon
-----Original Message-----
From: Michael Freedman
[mailto:]
Sent: Monday, April 15, 2002
3:21 PM
To: Eilon Reshef
Cc: 'Gil Tayar'; 'Sasha Aickin';
Subject: Re: [wsrp][interfaces]: Portal
Usage Scenario
I wonder if some of the confusion comes
from point-of-view. The terms I have set out to define are defined from
the perspective of the portal. At this point there are no assumptions or
terms defined from the perspective of the portlet. I.e. I have been
attempting to define how a portal interacts with a portlet through the
lifecycle of a bound service without discussing how this service models the
behaviors. For example -- from a portal perspective a portlet instance
is element in the portal the structure -- its likely that from a portlet
modeling perspective the API will represent the portals operations on the
instance as a runtime (only) thing. I.e. in the end the portal talks to
a portlet service for all operations (there aren't multiple
objects/services). Operations are defined not only by the method of the
service itself but by the (form of) data passed to the method.
As for whether we should define/discuss the design time -- First my goal
was to capture the portals perspective so we could discuss what WSRP should
concern itself with. In our concall last week, including portlet
templates (design-time) was discussed. A number of portal vendors
indicated they will need to define this behavior anyway -- and would prefer a
standard for it. We decided however to tackle the portlet instance case
first as it seemed more basic -- and once this level of the API was in good
shape to come back and look at portlet templates.
-Mike-
Eilon Reshef wrote:
See my answers below.
As Thomas noted, I think it's mainly a terminology question, but I think
it's important that eventually we all sync
up.My line of thought is that design-time is a pretty complex thing,
that we may or may not need to standardize, and there's a portal-specific or
portlet-specific workflow that results in possibly portlet templates,
all of which are persistent (so there could be an administrator portlet
template, then a superuser portlet template, then a portlet for an
individual user).Whenever an individual
views the page, then a portlet instance is created, to
generate the view.Eilon
-----Original Message-----
From: Gil Tayar [mailto:]
Sent: Sunday, April 14, 2002
2:11 AM
To:
'Sasha Aickin'; Michael Freedman
Cc:
Subject: RE: [wsrp][interfaces]: Portal
Usage Scenario
Mike,The definition for portlet instance as a "a
portlet in the portal layout structure" is still confusing. Let me ask a
question which will maybe make things clearer between us - if no user is
seeing a portal page, does a portlet instance
exist?If the answer is
yes, then a portlet instance is not (only?) a runtime
manifestation. Moreover, we do not have a name for the runtime
manifestation, and I feel we should.If the answer is no, then what is the
word for the design time manifestation? Is it the "portlet
template"?My feeling is that
there should be concensus on the answer to this question, so that we will
be on common ground on this very important term - portlet
instance.So, let me re-ask
the question (and I would really appreciate if all WSRP members
could answer), and make them more answerable
: 1. If no user is
seeing no portal page at a certain point in time, does a portlet instance
exist at that time?Answers:( ) Yes(
X ) No The portlet
instance is a run-time object
only. ( ) Other:
____________________________________________________________________2. If a user is
seeing a portal page at a certain point in time, is it the portlet
instance which is rendering the
portlet?Answers:(
X ) Yes Yes, the
portlet instance generates the markup in
run-time ( ) No( ) Other:
____________________________________________________________________Cheers,Gil
-----Original Message-----
From: Sasha Aickin [mailto:]
Sent: Friday, April 12, 2002
07:10
To:
Michael Freedman; Gil Tayar
Cc:
Subject: RE: [wsrp][interfaces]: Portal
Usage Scenario
Mike,I'd like to offer a slight
clarification, if I could: I think that WSRP/portlets care about a
clone only if the service maintains its personalization data AND the
portlet service has to maintain information about each portlet instance
on each page. I feel like, as I think Yossi said earlier, that the
portal could implement clone by simply including the same instance on
two pages. That way, WSRP would not need to know about cloning
even if the portlet service maintained personalization
data.Cheers,Sasha.
-----Original Message-----
From: Michael Freedman [mailto:]
Sent: Wednesday, April 10,
2002 2:24 PM
To: Gil Tayar
Cc:
Subject: Re: [wsrp][interfaces]:
Portal Usage Scenario
I believe that is
how we have defined things:
portlet
instance: a portlet on a page; or more generically a portlet in
the portal layout structure. From a portal's perspective, the
portlet instance is the realization of the portlet in the
runtime layout structure. A portlet instance is derived from a
portlet template. e.g. when adding a portlet to a page,
the user chooses a portlet template (from the toolbox).
The template is used to "type" the instance being created.
personalization data: a set of customized data
settings for a portlet instance. There is an 1 to N relationship
between personalization data and portlet instances. 1 set of
personalizations may be shared between multiple instances.
What is/was a little confusing was Yossi statement that "the same
portlet instance appears in different places in the portal
structure". That is not what I had indicated in my reply to him
-- rather I said was "personalization [data] can be shared between
multiple portlet instances of the same type." I.e. portlet
instances ARE your runtime manifestations on a page. There is a
special case where two of these happen to share the same
personalization data. This tends to come into existence
via some kind of clone operation. WSRP/portlets care about this
in the situation the service maintains its personalization data.
I hope this helps.
-Mike-
Gil Tayar wrote:
I second #1,
as I outlined in my previous email. I submit that what is confusing
is the term "portlet instance". I would prefer "portlet instance
data" or "portlet customization data" and leave "portlet instance"
to the runtime manifestation on the page, e.g. only when the user
views it.
-----Original Message-----
From: Tamari, Yossi [mailto:]
Sent: Tuesday, April
09, 2002 11:28
To:
Subject: RE:
[wsrp][interfaces]: Portal Usage Scenario
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-
