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
