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