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]
