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