If you did the POST with XHR you could embed the redirect logic in the client code rather than in the server. -Mikeal
On Wed, Oct 14, 2009 at 11:12 AM, Sven Helmberger <[email protected]>wrote: > Chris Anderson schrieb: > > On Wed, Oct 14, 2009 at 10:18 AM, Sven Helmberger >> <[email protected]> wrote: >> >>> Hi! >>> >>> I've been a web architect / developer for some time now and my main focus >>> has been standard-compliant, accessible web applications. One of the >>> points >>> that nag me the most are web applications that only work with javascript >>> enabled without having a clear reason to do so. Stuff like >>> Google Maps gets a free pass from me, but even Google Maps now supports >>> server-side image rendering to enable basic javascript-less use. >>> >>> The js-only property of Standalone CouchDB Applications is what really >>> puts >>> me off about them. Now I've been thinking about what it takes to enable >>> Standalone Applications working without client-side javascript. >>> >>> The recent addition of show and list functions goes a looong way in this >>> direction so that it seems to me that there are two things missing for it >>> to >>> be possible. >>> >>> First would be some kind of _external HTML-Form-Submit-to-CouchDB bridge >>> that takes parameters sent, parses them in some way and constructs a >>> new or changed CouchDB document. >>> >>> e.g. _id=xxx&name=Foo&tag.1=example&tag.2=accessible&sub.field=bar >>> >>> would be converted to >>> { >>> "_id" : "xxx", >>> "name": "Foo", >>> "tag" : ["example","accessible"], >>> "sub" : { >>> "field" : "bar" >>> } >>> } >>> >>> very similar how many webframework do binding into nested object graphs. >>> This is pretty much doable now as first tests seem to prove, with the >>> exception of CouchDB not seeming to support "multipart/form-data" encoded >>> requests. (it thinks binary files are UTF-8 and complains about invalid >>> encoding etc. when nothing in the request says anything about >>> UTF-8) >>> >> >> This should be possible with _update functions. The best documentation >> for these is still the test suite. >> >> The other thing that is missing would be a way to decide to what URL to >>> redirect to after receiving such a form submission, which obviously >>> shouldn't be done by just sending a hidden field with the URL >>> (maybe sign it in some way?) >>> >>> >> I also like the idea of a rewriter. >> >> > you mean like mod_rewrite on apache ? > > That is not really what I meant. > > Suppose you have a show function or a static attachment containing some > form for your app whose action points to the Form/CouchDB-Bridge. > > The question then is what happens after a document is stored/updated > correctly. where to redirect the user to? just back to the form view is not > really something I'd like to see as a standard behaviour. > > So there needs to be some kind of target configuration that can't just come > from the (hidden) form content unless it is signed to ensure that it's > really the application that is sending the user to that URL and not the > user's hacking attempts. > > Regards, > Sven Helmberger >
