Title: Message
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:]
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:]
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?
