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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

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


Subject: RE: [wsrp-interfaces] Re: [wsrp-wsia] Re: [wsrp][wsia][wsrp-wsia jointitnerfaces] Actions


Title: Message
Mike, Rich,
 
Another twist to this discussion comes from the customization efforts within WSIA.
 
In this case, the Consumer needs to carry out a dialog with the Producer AFTER the action is invoked but BEFORE the output is generated. (Think of a scenario where the action is the "Next" button that scrolls to the next set of records, but the Consumer wants to intervene as the page is generated, to change some of the data). Separation of actions and presentation is one way to accomplish this (although not the only one).
 
As Rich suggested, I believe this should be optional so that one operation (the spec proposal calls it performAction) can handle the data and return presentation. I don't think this will be foreign to the average ASP/JSP developer, because although these models combine processing with output generation (a single ASP page processes the input and generates HTML), many J2EE frameworks do separate between the two. And, Web programmers often use a client-side redirect after data POST to avoid a re-post in the case of the user refreshing the page.
 
My two cents,
Eilon
 
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Tuesday, June 18, 2002 3:53 PM
To: interfaces; wsrp-wsia
Subject: [wsrp-interfaces] Re: [wsrp-wsia] Re: [wsrp][wsia][wsrp-wsia joint itnerfaces] Actions


Another way of phrasing this questions is when should the input to an
entity be anything more than a set of property changes. I think the answer
is when the user action semantically implies invoking application logic.
Could this always be modelled as a set of property changes that the entity
"listens" to in order to fire the logic? Yes, but that is not always a
convenient way to model the application (often involves introducing
properties just to fire off the logic) nor the way many developers think
when authoring an app.

Now Gil has commented more than once on the opposite approach. That one is
always performing an action, its just that sometimes the actionName is null
(ie. semantically a getFragments). I think before we collapse the
operations in that fashion, we had better work through what the lifecycle
of a user interaction looks like. I think on a logical level this should
be:
   1. Apply the state change directly indicated by the user action. (set
properties & fire logic)
   2. Ripple relevant state changes to interested parties (I think this is
needed by the Coordinated use case)
   3. Gather page fragments reflecting new state.



                                                                                                                    
                      Michael Freedman                                                                              
                      <Michael.Freedman@        To:       Carsten Leue/Germany/IBM@IBMDE                            
                      oracle.com>               cc:       interfaces <wsrp-interfaces@lists.oasis-open.org>,        
                                                 wsrp-wsia <wsrp-wsia@lists.oasis-open.org>                         
                      06/18/2002 03:17          Subject:  [wsrp-wsia] Re: [wsrp][wsia][wsrp-wsia joint itnerfaces]  
                      PM                         Actions                                                            
                                                                                                                    
                                                                                                                    
                                                                                                                    



Carsten,
    Thanks. I think I have been a little too harsh in saying I don't
understand "actions".  I understand the basic intent of actions, and your
summary reinforces it.  However, I recognize that "actions" aren't
currently modeled in the web application programming world.  However, a
developer
could certainly mimic the separation of data processing from rendering
within such an environment.  I ask myself why shouldn't a JSP programmer be
able to write a portlet?  Actions potentially restrict this (and they
certainly do in the JSR 168 definition).  Because of all this I tend to
start
with the point of view the simplest/generic portlet only needs getFragment.
I am looking to understand/define when to tell these developers that
they must move/use actions.  I prefer this is not whenever you need to
process data -- as this is something that is currently commonly done in
getFragment (web programming).
   -Mike-

Carsten Leue wrote:

> Mike - here comes my view on things:
>
> The user has basically two different possiblities to operate a portlet:
he
> can "view" the portlet and he can "interact" with the portlet. With
> "interact" I mean that he can send data to the portlet (e.g. form data)
or
> just send a command (= action) to the portlet (e.g. by clicking on a link
> that has a special signification to the portlet). Think of the example of
a
> newsfeed portlet that allows the user to browse through multiple pages.
In
> such a portlet you would need a "link" that make the portlet switch to
the
> next page and a link to switch to the previous page.
>
> So there are two semantically different functions for the portlet to
> perform:
> 1. representing the current state as markup
> 2. modifying the current state based on a command (= action)
>
> The first function is expressed by "getFragments" the second one by
> "performAction".
>
> Principally the getFragments method must at least return the markup to
> display, whereas the performAction method does not necessarily need to
> return markup.
> However we decided to let the performAction method return markup for
> performance reasons as it saves one additional call to getFragments after
> the action has been performed. Semantically this would not have been
> necessary.
>
> Best regards
> Carsten Leue
>
> -------
> Dr. Carsten Leue
> Dept.8288, IBM Laboratory Böblingen , Germany
> Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
>
> |---------+----------------------------->
> |         |           Michael Freedman  |
> |         |           <Michael.Freedman@|
> |         |           oracle.com>       |
> |         |                             |
> |         |           06/12/2002 02:33  |
> |         |           AM                |
> |         |           Please respond to |
> |         |           Michael Freedman  |
> |         |                             |
> |---------+----------------------------->
>   >
---------------------------------------------------------------------------------------------------------------------------------------------|

>   |
|
>   |       To:       wsia <wsia@lists.oasis-open.org>, WSRP
<wsrp@lists.oasis-open.org>
|
>   |       cc:
|
>   |       Subject:  [wsrp][wsia][wsrp-wsia joint itnerfaces] Actions
|
>   |
|
>   |
|
>   >
---------------------------------------------------------------------------------------------------------------------------------------------|

>
> I would like to open another discussion parallel to our session debate.
> From the perspective of the protocol defined in the latest draft I can't
> figure out the semantic difference between performAction and
> getFragment.  Each seem to be capable of returning the same stuff.  Why
> do we need both?  I.e. how are they semantically different?
>      -Mike-
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>






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