[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp][interfaces]: Portal Usage Scenario
I want to point out that there may be other things to key the
configuration/customization information off of. User groups and
specific pages are two additional levels of customization information
that are important to me.
Sasha.
-----Original Message-----
From: Thomas Schaeck [mailto:SCHAECK@de.ibm.com]
Sent: Monday, April 15, 2002 1:06 PM
To: wsrp@lists.oasis-open.org
Subject: Re: [wsrp][interfaces]: Portal Usage Scenario
Gil,
with "configuration" of a portlet template I meant the user-independent
settings of a portlet template (e.g. a news feed to be used by the
portlet
template) - i.e. the data that really defines what the template is.
With "customization" of a portlet template I meant the user or
user-group
specific customization (e.g. selecting news topics of interest based on
the
news feeds defined in the configuration of the portlet template)
I'll try to further improve the definitions ...
Best regards,
Thomas
Gil Tayar <Gil.Tayar@webcollage.com> on 04/15/2002 02:05:50 PM
Please respond to Gil Tayar <Gil.Tayar@webcollage.com>
To: Thomas Schaeck/Germany/IBM@IBMDE
cc: "'Sasha Aickin'" <AlexanderA@plumtree.com>, Michael Freedman
<Michael.Freedman@oracle.com>, wsrp@lists.oasis-open.org
Subject: Re: [wsrp][interfaces]: Portal Usage Scenario
OK. That _is_ clearer. I would propose using "active portlet instance"
instead of "portlet view", but I'm not strong on both.
Assuming no objections - I propose on these being the definitions for
the
terms discussed in this email.
Your definitions have something else I don't understand, and will maybe
help
me understand the difference between a template and an instance: what is
a
"configuration" (template), and what is a "customization" (instance)?
Gil
-----Original Message-----
From: Thomas Schaeck [mailto:SCHAECK@de.ibm.com]
Sent: Sunday, April 14, 2002 13:53
To: Gil Tayar
Cc: 'Sasha Aickin'; Michael Freedman; wsrp@lists.oasis-open.org
Subject: RE: [wsrp][interfaces]: Portal Usage Scenario
I think this may just be a naming issue (see my other note).
I'd propose to use the following wording:
Portlet Template:
-----------------
A portlet template is a persistent entity that defines a configuration
of a
portlet service that is global to all users.
Note:In portal UIs, from a user view, portlet instances are typically
visible as "Portlets" that can be selected in a customizer/toolbar for
creation of a ->Portlet Instance on a page.
Portlet Instance:
-----------------
A portlet instance is a persistent entity that defines a customization
of a
portlet template. A portlet instance may directly or indirectly be
related
to individual users or groups of users, typically it is *not* global to
all
users.
Note: In portals, portlet instances typically are created by users
selecting portlet templates for creation of an instance associated with
a
page, with the result that a ->portlet view of the portlet instance is
rendered whenever the page is displayed at runtime. In portals that have
a
customizer with a copy / clone function for portlet instances, portlet
instances may be referenced from multiple pages.
Portlet View:
-------------
A portlet view is the runtime manifestation of a ->portlet instance as a
markup fragment aggregated in a portal page.
Filled out form see below ...
Best regards,
Thomas
Gil Tayar <Gil.Tayar@webcollage.com> on 04/14/2002 08:10:35 AM
Please respond to Gil Tayar <Gil.Tayar@webcollage.com>
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 (because the instance is a persistent entity, it exists from
creation until being destroyed.
( ) 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
(X) No (the WSRP portlet service is called with the instance handle for
the
instance to be rendered and the portlet service renders markup based on
the
instance state)
( ) 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-
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC