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
( ) No
( ) 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:
( ) Yes
( ) No
( ) Other:
____________________________________________________________________
Cheers,
Gil
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.
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.
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.
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.
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-
|