[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp-interfaces] Re: [wsrp-wsia] Re: [wsrp][wsia][wsrp-wsia jointitnerfaces] 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC