[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp][interfaces]: Portal Usage Scenario
Gil - I checked your checkboxes as an answer.
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory Böblingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
|---------+---------------------------->
| | Gil Tayar |
| | <Gil.Tayar@webcol|
| | lage.com> |
| | |
| | 04/14/2002 08:10 |
| | AM |
| | Please respond to|
| | Gil Tayar |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: "'Sasha Aickin'" <AlexanderA@plumtree.com>, Michael Freedman <Michael.Freedman@oracle.com> |
| cc: wsrp@lists.oasis-open.org |
| 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:
(x) 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:
(x) Yes
( ) No
( ) Other:
____________________________________________________________________
Cheers,
Gil
-----Original Message-----
From: Sasha Aickin [mailto:AlexanderA@plumtree.com]
Sent: Friday, April 12, 2002 07:10
To: Michael Freedman; Gil Tayar
Cc: wsrp@lists.oasis-open.org
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:Michael.Freedman@oracle.com]
Sent: Wednesday, April 10, 2002 2:24 PM
To: Gil Tayar
Cc: wsrp@lists.oasis-open.org
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:yossi.tamari@sapportals.com]
Sent: Tuesday, April 09, 2002 11:28
To: wsrp@lists.oasis-open.org
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:Michael.Freedman@oracle.com]
Sent: Tuesday, April 09, 2002 12:06 AM
To: Tamari, Yossi
Cc: wsrp@lists.oasis-open.org
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:Michael.Freedman@oracle.com
]
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-
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC