You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Michael Jouravlev <jm...@gmail.com> on 2006/04/19 03:19:53 UTC
A clean way to separate "view" actions from "update" actions
I decided to pull this out to the mailing list to keep Rough Spots
page [1] cleaner.
crazybob: "Come up with a clean way to separate "view" actions from
"update" actions. ... [As one of the options] we could flag action
invocations as "view" or "update" (using an enum). We could
automatically choose a mode based on whether the request is an HTTP
GET or POST."
MichaelJ: "Using GET for render and POST for submit works well unless
you want to trigger event with a link."
crazybob: "Triggering an event should still be a POST (though the
framework should make it easy). From the HTTP spec.: 'GET and HEAD
methods SHOULD NOT have the significance of taking an action other
than retrieval.'"
What actually should be done by a particular developer of a particular
application is a religious question. There is no legal way known to me
that allows to send POST request via a link without using Javascript.
Web applications take actions and change their state using links all
the time. Heck, take any web-based client, be it GMail or Yahoo, they
use links. Take CRUD application, the view/edit/delete actions are
usually made with links because putting three buttons on every line
would look ugly (well, modern apps use Javascript and highlighing, but
this is another story). I've been there and came back. Yes, using POST
is cleaner HTTP-wise, but the goal of a framework is to simplify
programmers' job, not to prohibit them from doing something.
Also if you noticed, HTTP spec says "SHOULD NOT", not "MUST NOT". So,
using GET is not prohibited, it is simply frowned upon, but as I said
everyone uses links for actions and state change.
Therefore, while a framework should teach good practices, it should
not prohibit from something that is technically feasible, but just
unacceptable for framework designers. I don't want framework to work
against me. Need no gods (have I already said that?)
So, as you responded, triggering an event *should* be a POST, but it
is not like it *must be*. Framework should allow to use both POST and
GET to trigger an event. Obviously, using POST vs. GET as a division
point between submit and render is simple. Therefore it might be
sensible to agree, that POST always triggers input phase, while GET
requires further screening.
I suggest taking a look at EventActionDispatcher [2] class and its
usage in Struts 1.x [3]. Basically, you define events that an action
(sorry, actionbean) responds to. If event is found in the request,
this is input phase. Appropriate event handler is called, as well as
validation/conversion (though I would really-really prefer to call
validation/conversion/etc manually without having to implement a bunch
of interfaces). If event is not found, then this is a render phase.
Plain and simple.
Michael.
[1] http://wiki.apache.org/struts/RoughSpots
[2] http://wiki.apache.org/struts/EventActionDispatcher
[3] http://wiki.apache.org/struts/DataEntryForm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: A clean way to separate "view" actions from "update" actions
Posted by Bob Lee <cr...@crazybob.org>.
I'll buy that, but users should understand that malicious users can
put HTML like this on other sites:
<img src="http://yoursite/deleteAccount">
That's not to say that POSTs are 100% immune to this sort of thing.
They're just slightly less susceptible. The safe solution is to emded
some sort of unique token in the URL, but I'll leave that topic for
another day.
This is why I went on to say, "or we could set the mode based on an
annotation on the action method. Or some other way... "
My thinking is we could set the mode based on GET/POST and let users
override it in the Struts configuration or using annotations.
Bob
On 4/18/06, Michael Jouravlev <jm...@gmail.com> wrote:
> I decided to pull this out to the mailing list to keep Rough Spots
> page [1] cleaner.
>
> crazybob: "Come up with a clean way to separate "view" actions from
> "update" actions. ... [As one of the options] we could flag action
> invocations as "view" or "update" (using an enum). We could
> automatically choose a mode based on whether the request is an HTTP
> GET or POST."
>
> MichaelJ: "Using GET for render and POST for submit works well unless
> you want to trigger event with a link."
>
> crazybob: "Triggering an event should still be a POST (though the
> framework should make it easy). From the HTTP spec.: 'GET and HEAD
> methods SHOULD NOT have the significance of taking an action other
> than retrieval.'"
>
> What actually should be done by a particular developer of a particular
> application is a religious question. There is no legal way known to me
> that allows to send POST request via a link without using Javascript.
> Web applications take actions and change their state using links all
> the time. Heck, take any web-based client, be it GMail or Yahoo, they
> use links. Take CRUD application, the view/edit/delete actions are
> usually made with links because putting three buttons on every line
> would look ugly (well, modern apps use Javascript and highlighing, but
> this is another story). I've been there and came back. Yes, using POST
> is cleaner HTTP-wise, but the goal of a framework is to simplify
> programmers' job, not to prohibit them from doing something.
>
> Also if you noticed, HTTP spec says "SHOULD NOT", not "MUST NOT". So,
> using GET is not prohibited, it is simply frowned upon, but as I said
> everyone uses links for actions and state change.
>
> Therefore, while a framework should teach good practices, it should
> not prohibit from something that is technically feasible, but just
> unacceptable for framework designers. I don't want framework to work
> against me. Need no gods (have I already said that?)
>
> So, as you responded, triggering an event *should* be a POST, but it
> is not like it *must be*. Framework should allow to use both POST and
> GET to trigger an event. Obviously, using POST vs. GET as a division
> point between submit and render is simple. Therefore it might be
> sensible to agree, that POST always triggers input phase, while GET
> requires further screening.
>
> I suggest taking a look at EventActionDispatcher [2] class and its
> usage in Struts 1.x [3]. Basically, you define events that an action
> (sorry, actionbean) responds to. If event is found in the request,
> this is input phase. Appropriate event handler is called, as well as
> validation/conversion (though I would really-really prefer to call
> validation/conversion/etc manually without having to implement a bunch
> of interfaces). If event is not found, then this is a render phase.
> Plain and simple.
>
> Michael.
>
> [1] http://wiki.apache.org/struts/RoughSpots
> [2] http://wiki.apache.org/struts/EventActionDispatcher
> [3] http://wiki.apache.org/struts/DataEntryForm
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: A clean way to separate "view" actions from "update" actions
Posted by Eric Molitor <em...@molitor.org>.
Could/should the "nice to haves" be moved to their own page? There are
a few items that I'd like to add but they are not really appropriate
for the rough spots page.
Cheers,
Eric
On 4/18/06, Bob Lee <cr...@crazybob.org> wrote:
> Also, the first couple paragraphs in the DefaultActionMapper section
> describe how WebWork handles this sort of dispatching:
>
> http://opensymphony.com/webwork/wikidocs/ActionMapper.html
>
> Bob
>
> On 4/18/06, Michael Jouravlev <jm...@gmail.com> wrote:
> > I decided to pull this out to the mailing list to keep Rough Spots
> > page [1] cleaner.
> >
> > crazybob: "Come up with a clean way to separate "view" actions from
> > "update" actions. ... [As one of the options] we could flag action
> > invocations as "view" or "update" (using an enum). We could
> > automatically choose a mode based on whether the request is an HTTP
> > GET or POST."
> >
> > MichaelJ: "Using GET for render and POST for submit works well unless
> > you want to trigger event with a link."
> >
> > crazybob: "Triggering an event should still be a POST (though the
> > framework should make it easy). From the HTTP spec.: 'GET and HEAD
> > methods SHOULD NOT have the significance of taking an action other
> > than retrieval.'"
> >
> > What actually should be done by a particular developer of a particular
> > application is a religious question. There is no legal way known to me
> > that allows to send POST request via a link without using Javascript.
> > Web applications take actions and change their state using links all
> > the time. Heck, take any web-based client, be it GMail or Yahoo, they
> > use links. Take CRUD application, the view/edit/delete actions are
> > usually made with links because putting three buttons on every line
> > would look ugly (well, modern apps use Javascript and highlighing, but
> > this is another story). I've been there and came back. Yes, using POST
> > is cleaner HTTP-wise, but the goal of a framework is to simplify
> > programmers' job, not to prohibit them from doing something.
> >
> > Also if you noticed, HTTP spec says "SHOULD NOT", not "MUST NOT". So,
> > using GET is not prohibited, it is simply frowned upon, but as I said
> > everyone uses links for actions and state change.
> >
> > Therefore, while a framework should teach good practices, it should
> > not prohibit from something that is technically feasible, but just
> > unacceptable for framework designers. I don't want framework to work
> > against me. Need no gods (have I already said that?)
> >
> > So, as you responded, triggering an event *should* be a POST, but it
> > is not like it *must be*. Framework should allow to use both POST and
> > GET to trigger an event. Obviously, using POST vs. GET as a division
> > point between submit and render is simple. Therefore it might be
> > sensible to agree, that POST always triggers input phase, while GET
> > requires further screening.
> >
> > I suggest taking a look at EventActionDispatcher [2] class and its
> > usage in Struts 1.x [3]. Basically, you define events that an action
> > (sorry, actionbean) responds to. If event is found in the request,
> > this is input phase. Appropriate event handler is called, as well as
> > validation/conversion (though I would really-really prefer to call
> > validation/conversion/etc manually without having to implement a bunch
> > of interfaces). If event is not found, then this is a render phase.
> > Plain and simple.
> >
> > Michael.
> >
> > [1] http://wiki.apache.org/struts/RoughSpots
> > [2] http://wiki.apache.org/struts/EventActionDispatcher
> > [3] http://wiki.apache.org/struts/DataEntryForm
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: A clean way to separate "view" actions from "update" actions
Posted by Bob Lee <cr...@crazybob.org>.
Also, the first couple paragraphs in the DefaultActionMapper section
describe how WebWork handles this sort of dispatching:
http://opensymphony.com/webwork/wikidocs/ActionMapper.html
Bob
On 4/18/06, Michael Jouravlev <jm...@gmail.com> wrote:
> I decided to pull this out to the mailing list to keep Rough Spots
> page [1] cleaner.
>
> crazybob: "Come up with a clean way to separate "view" actions from
> "update" actions. ... [As one of the options] we could flag action
> invocations as "view" or "update" (using an enum). We could
> automatically choose a mode based on whether the request is an HTTP
> GET or POST."
>
> MichaelJ: "Using GET for render and POST for submit works well unless
> you want to trigger event with a link."
>
> crazybob: "Triggering an event should still be a POST (though the
> framework should make it easy). From the HTTP spec.: 'GET and HEAD
> methods SHOULD NOT have the significance of taking an action other
> than retrieval.'"
>
> What actually should be done by a particular developer of a particular
> application is a religious question. There is no legal way known to me
> that allows to send POST request via a link without using Javascript.
> Web applications take actions and change their state using links all
> the time. Heck, take any web-based client, be it GMail or Yahoo, they
> use links. Take CRUD application, the view/edit/delete actions are
> usually made with links because putting three buttons on every line
> would look ugly (well, modern apps use Javascript and highlighing, but
> this is another story). I've been there and came back. Yes, using POST
> is cleaner HTTP-wise, but the goal of a framework is to simplify
> programmers' job, not to prohibit them from doing something.
>
> Also if you noticed, HTTP spec says "SHOULD NOT", not "MUST NOT". So,
> using GET is not prohibited, it is simply frowned upon, but as I said
> everyone uses links for actions and state change.
>
> Therefore, while a framework should teach good practices, it should
> not prohibit from something that is technically feasible, but just
> unacceptable for framework designers. I don't want framework to work
> against me. Need no gods (have I already said that?)
>
> So, as you responded, triggering an event *should* be a POST, but it
> is not like it *must be*. Framework should allow to use both POST and
> GET to trigger an event. Obviously, using POST vs. GET as a division
> point between submit and render is simple. Therefore it might be
> sensible to agree, that POST always triggers input phase, while GET
> requires further screening.
>
> I suggest taking a look at EventActionDispatcher [2] class and its
> usage in Struts 1.x [3]. Basically, you define events that an action
> (sorry, actionbean) responds to. If event is found in the request,
> this is input phase. Appropriate event handler is called, as well as
> validation/conversion (though I would really-really prefer to call
> validation/conversion/etc manually without having to implement a bunch
> of interfaces). If event is not found, then this is a render phase.
> Plain and simple.
>
> Michael.
>
> [1] http://wiki.apache.org/struts/RoughSpots
> [2] http://wiki.apache.org/struts/EventActionDispatcher
> [3] http://wiki.apache.org/struts/DataEntryForm
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org