Title: Message
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-
