couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: Standalone CouchDB Applications without Javascript
Date Wed, 14 Oct 2009 17:40:15 GMT
On Wed, Oct 14, 2009 at 10:18 AM, Sven Helmberger
<sven.helmberger@gmx.de> 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.

> How does this sound?
> Any thoughts about it?
>
> Regards,
> Sven Helmberger
>



-- 
Chris Anderson
http://jchrisa.net
http://couch.io

Mime
View raw message