couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikeal Rogers <>
Subject Re: Standalone CouchDB Applications without Javascript
Date Wed, 14 Oct 2009 18:14:51 GMT
If you did the POST with XHR you could embed the redirect logic in the
client code rather than in the server.

On Wed, Oct 14, 2009 at 11:12 AM, Sven Helmberger <>wrote:

> Chris Anderson schrieb:
>  On Wed, Oct 14, 2009 at 10:18 AM, Sven Helmberger
>> <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message