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


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.


-----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
that the portlet template reflects the state a portlet instance would
if it is created with only the persistent preferences (data / profile /
properties ... whatever the term is), regardless of where those
are persisted. A portlet instance represents the runtime entity, which
also have transient data settings.


                      Eilon Reshef

                      <eilon.reshef@webc        To:       "'Sasha
Aickin'" <AlexanderA@plumtree.com>, "'WSRP'"  

                      04/11/2002 10:31          Subject:  RE: [wsrp]




I see your point.

I assume that in this scenario, the preferences are persistent... does
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
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
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
      To: WSRP
      Subject: RE: [wsrp] Divide-and-Conquer Interfaces-and-Protocols


      I basically agree with what you say here, with the following

      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
      (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
            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
            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.
            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
            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
            because the design-time considerations seem to be pretty
            specific to portals whereas the run-time considerations seem
            overlap more with WSIA and may require more collaboration

            In addition, it seems that design-time considerations may
            themselves more to extensibility (vendor-specific
            whereas the run-time aspects seem to demand tight

            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

            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