Title: Message
The definitions below capture the semantics very
clearly - how about the term instance data as an alternative to
personalization data? I guess the data is not necessarily personalized
in the strict sense (i.e., a team page with a portlet still has
instance-specific data, but it's not user-specific), and on the other hand this
is the data on which an instance operates. Would it make it clearer? (E.g., "by
default, each instance has its own instance data, but it is possible that
multiple instances share the same instance data, possibly because they are
cloned")
-----Original Message-----
From: Michael Freedman
[mailto:]
Sent: Wednesday, April 10,
2002 5: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-
