Portals typically know their structure (what portlets are on what pages)
persistently. So from a portal's perspective a portlet instance exists
-- i.e.. its represented in its persistent knowledge of the structure even
though the page isn't currently being viewed.
-Mike-
Eilon Reshef wrote:
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
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
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
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-
|