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:]
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-wsia
<>
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鐽lingen , 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
<>, WSRP
<>
|
> |
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>
