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

[Rich Thompson <richt2@us.ibm.com>]

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?