Mike,
An "action" is, in my opinion, a very pompous way of
saying that the user has clicked on a link or submitted a form in the service.
That's all. Usually in a Web app, the "action" is sent as a GET/POST to the Web
Server which returns presentation.
In the WSIA/WSRP world, this is impossible, because if
that happened, then the user would "leak" out of the Consumer pages. So the link
is rewritten to go "back" to the Consumer page, with an "action" parameter. The
Consumer reads the action parameter, and sends that "action" using the
"performAction".
There are two views on what happens on the first page
(in which no "action" is done), and what happens during an "[F5]" refresh (in
which the action need or need not be done).
The first view, detailed in the WSXL
proposal, is that since there is no "action", then the "getMarkup" must be
called.
The second view, detailed in the IWS proposal, is that
in the first page there is a special action name (empty, or "start" or
something), and in the refresh case you just resend the action (which is what
would happen in a normal Web app - the form would be reposted or the GET would
be re-sent). In any case, in the IWS proposal, there is only
performAction.
Gil
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>
|