Re: [wsrp-interfaces] Re: [wsrp-wsia] Re: [wsrp][wsia][wsrp-wsiajointitnerfaces] Actions

[Michael Freedman <Michael.Freedman@oracle.com>]

I agree with your logical levels.  My question is whether we impose the model on all developers whether or not they need step (b) "ripple state
changes to interested parties"?
I would prefer a model that defines actions as only required if (b) is to be supported and just "encouraged" in other cases as we consider
separating (a) and (c) "good programming practice".  Put another way, I prefer a spec that says that getFragment is sufficient unless one needs to
ripple state changes to others.

Note:  there might be another [unnamed] expert group working on a similar problem at a higher level that I also participate on that pretty much
follows the above.  The one twist they added was to encourage more use of the model when (b) doesn't exist by defining two types of actions:
blocking and non-blocking.  Blocking maps to your logical levels (a), (b), and (c).  Non-blocking is essentially a forced separation via the
protocol between data processing and rendering without perturbing the processing of other portlets.
     -Mike-

Rich Thompson wrote:

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