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-
