On May 10, 2005, at 5:44 AM, Titus Brown wrote:
> -> I'm not sure that Quixote does anything that actually needs to be
> -> fixed.  The fact that it doesn't, by default, differentiate between
> -> GET and POST is a little suboptimal.  It also makes it easy to
> -> violate this design principle.  Miguel has no sympathy:
> ->
> ->   http://primates.ximian.com/~miguel/archive/2005/May-08.html
> ->
> -> The Ruby on Rails guys are planning to work around the inconvenience
> -> of using GETs:
> ->
> ->   http://www.loudthinking.com/arc/000455.html
> ->
> -> I guess Quixote could provide a utility function if the link_to idea
> -> catches on.

Is it not the client that issues the GET or POST... or the DELETE. But,
which web clients ever know when to do this? (The METHOD attribute of
FORM only accepts GET and POST, at least for html 4...)

So, such a link_to means that all GETs are issued as POSTs, and
translated to a GET by the server?
But that loses too much client functionality... the convenience of
having a bookmarkable url, for example ?!?

I must be missing something here.

> It might be worth mentioning it somewhere in the docs.  Certainly I've
> found that the 'object/delete' functionality is, umm, too obvious not
> to
> use ;).

Yes. All actions that modify actually... I guess however that GET urls
for object/modify or object/delete are only for loading (getting) the
object info plus the appropriate submit buttons (assuming we are
talking about an html interface). Submitting from that document will
issue the actual post (modify) or delete http requests.... Anyone know
of a nicely done web application that is built this way?

mario