[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp] Divide-and-Conquer Interfaces-and-Protocols
I would not see the user specific persistent prefs as a portlet instance,
but as another portlet template which was created from the portal-wide
portlet template. This is still logically distinct from the portlet
instance that is presented to the End-User for interaction. There are
issues involved in how a portal would manage such scoping of templates, but
I'm not convinced it has interface implications for interacting with the
portlet service.
"Sasha Aickin"
<AlexanderA@plumt To: Rich Thompson/Watson/IBM@IBMUS,
ree.com> <wsrp@lists.oasis-open.org>
cc:
04/12/2002 11:56 Subject: RE: [wsrp] Divide-and-Conquer
AM Interfaces-and-Protocols
Rich,
I'm not sure that a transient vs. persistent distinction is what we're
getting at here. Take an e-mail portlet, for example. The e-mail
portlet template may have persistent data for where the mail server is,
but a portlet instance would have information about which mailbox you
wanted to see. The portlet instance prefs/data/profile/properties would
be persistent, just as the portlet template
prefs/data/profile/properties would be persistent.
The difference to me between these entities is the scope of the prefs.
Portlet template prefs are per portal (i.e. all users in the portal on
all pages for a specific portlet template get the same values of these
prefs), whereas portlet instance prefs are per user per portlet per page
(i.e. each portlet instance running on a particular page for a
particular user has different values). This obviously gets back to the
question of levels of prefs, which I think we may not be able to avoid.
Cheers,
Sasha.
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Friday, April 12, 2002 8:38 AM
To: wsrp@lists.oasis-open.org
Subject: RE: [wsrp] Divide-and-Conquer Interfaces-and-Protocols
My view of how these logical entities may map into more concrete forms
is
that the portlet template reflects the state a portlet instance would
have
if it is created with only the persistent preferences (data / profile /
properties ... whatever the term is), regardless of where those
preferences
are persisted. A portlet instance represents the runtime entity, which
may
also have transient data settings.
Eilon Reshef
<eilon.reshef@webc To: "'Sasha
Aickin'" <AlexanderA@plumtree.com>, "'WSRP'"
ollage.com>
<wsrp@lists.oasis-open.org>
cc:
04/11/2002 10:31 Subject: RE: [wsrp]
Divide-and-Conquer
PM
Interfaces-and-Protocols
Sasha,
I see your point.
I assume that in this scenario, the preferences are persistent... does
it
make sense in this case to say that there are two ways to look at the
use-case then, one is that the user is essentially editing the portlet
template, which is the persistent entity, and naturally next time around
the portlet instance will be created based on the new template, or
alternatively, that the user is editing the portlet instance, and parts
of
it are persistent.
I guess my possibly over-simplistic thought was that we can try to
associate portlet templates with the persistent state and portlet
instances
with the transient state (all of which is regardless of the question of
where the persistent state is stored).
Eilon
-----Original Message-----
From: Sasha Aickin [mailto:AlexanderA@plumtree.com]
Sent: Thursday, April 11, 2002 9:48 PM
To: WSRP
Subject: RE: [wsrp] Divide-and-Conquer Interfaces-and-Protocols
Eilon,
I basically agree with what you say here, with the following
caveats:
Portlet instances that are personalized do not have as clear a
distinction between run-time and design-time as those without
personalization. For example, an e-mail portlet may have a
personalization page that asks what fields the end user wants to
see
(sender, received date, etc.), and this personalization should be
accessible at any time. An end user who sets these kinds of
personalization preferences is performing desing operations on the
portlet instance.
Does this make sense?
Sasha.
-----Original Message-----
From: Eilon Reshef [mailto:eilon.reshef@webcollage.com]
Sent: Thursday, April 04, 2002 9:17 PM
To: 'WSRP'
Cc: 'Michael Freedman'
Subject: [wsrp] Divide-and-Conquer Interfaces-and-Protocols
One random thought on a way to divide-and-conquer the work
around interfaces and protocols around the timing of the
protocol/interface invocation, i.e., one of two:
Some things happen in run-time, assuming the portal page is
already well defined and configured (in our terminology,
there's a portlet template that's already completely
configured), and an end user comes to the page. Under this
category fall all the issues with regards to the portlet
instance: rendering of the portlet page,
action/events/getContent, URL rewriting, user
identification,
and so on.
Some things happen in design-time, assuming that a portal
designer or an administrator is working to configure the
portlet and/or the portal page. These issues deals mainly
with
the portlet template: find/bind, interface discovery,
copy/clone, portal identity, and the workflow around
administrating the template data.
This is not to say that from a workflow perspective, there
couldn't be interleaving steps of run-time and design-time.
For
example, an administrator could set up a portlet and use its
"admin" mode (which itself employs a portlet instance) to
configure some template settings (although at this stage the
template is not "end-user-ready" yet), then a portal
designer
sets more template settings, and so on, until eventually the
template is exposed to the end user.
A couple of reasons why this categorization may be relevant
is
because the design-time considerations seem to be pretty
specific to portals whereas the run-time considerations seem
to
overlap more with WSIA and may require more collaboration
with
WSIA.
In addition, it seems that design-time considerations may
lend
themselves more to extensibility (vendor-specific
workflows),
whereas the run-time aspects seem to demand tight
interoperability.
And finally, there may be some different technical
requirements, for example - performance seems to be a key
consideration for run-time but not necessarily for
design-time.
Thoughts, comments, ideas?
----------------------------------------------------------------
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