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