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)
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?)
How does this sound?
Any thoughts about it?
Regards,
Sven Helmberger
