+1 to allowing the http method to be set/overwritten in a request parameter
Michael On 12/18/07, Lars Trieloff <[EMAIL PROTECTED]> wrote: > > Mindquarry has a filter that covers the first part, so ?http-X-HTTP- > Method-header=PUT would be changed to the corresponding header (our > pattern is http-(.*)-header), so all you have to do is adding a hidden > field like > > <input name="http-X-HTTP-Method-header" value="PUT"> to your form. An > even more easy to use solution would be the introduction of a > <sling:form> JSP tag, that would insert this hidden field > automatically for if the method of the form was not GET or POST. > > regards, > > Lars > > On 18.12.2007, at 13:09, Felix Meschberger wrote: > > > Am Dienstag, den 18.12.2007, 12:40 +0100 schrieb Lars Trieloff: > >> At least with µjax we have more control over the client than with > >> standard web forms, and even then, a concatenation of two > >> ServletFilters* and a hidden field could make a POST request into a > >> PUT request. So the server-side development can clearly separate the > >> concepts. > >> > >> * ServletFilters: 1st changes Request-Parameters with a certain > >> naming > >> pattern into request headers. This overcomes the disability of web > >> browsers to set headers programatically. > >> 2nd uses a header like X-HTTP-Method to override the HTTP method. > > > > Sounds like proper separation of concern. For maximum ease of use, I > > would assume the same names acceptable for the parameters in the first > > filter as are used for the request header in the second filter. > > > > Regards > > Felix > > > >> > >> Lars > >> > >> On 17.12.2007, at 23:03, Felix Meschberger wrote: > >> > >>> Am Freitag, den 14.12.2007, 19:59 +0100 schrieb Tobias Bocanegra: > >>>>> Why not use something like custom headers like X-HTTP-Method and a > >>>>> servlet filter to wrap PUTs in POSTs? > >>>>> > >>>>> As we control the client API, this is a cleaner way to do this > >>>>> IMHO. > >>>> > >>>> but we do not control the client. the goal is to use simple html > >>>> forms... > >>> > >>> That is only partly true of course: We define a protocol to use when > >>> sending data or requesting content to be stored or created. So, if > >>> we > >>> require a specific parameter (agreed, that headers more involved and > >>> won't work with simple forms), it is just part of the protocol... > >>> > >>> Regards > >>> Felix > >>> > >> > >> -- > >> Lars Trieloff > >> [EMAIL PROTECTED] > >> http://weblogs.goshaky.com/weblogs/lars > >> > > > > -- > Lars Trieloff > [EMAIL PROTECTED] > http://weblogs.goshaky.com/weblogs/lars > > -- Michael Marth, http://dev.day.com