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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
