OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [wsrp] Divide-and-Conquer Interfaces-and-Protocols

Title: Message
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).
-----Original Message-----
From: Sasha Aickin [mailto:AlexanderA@plumtree.com]
Sent: Thursday, April 11, 2002 9:48 PM
Subject: RE: [wsrp] Divide-and-Conquer Interfaces-and-Protocols

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?
-----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?

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC