couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sven Helmberger <sven.helmber...@gmx.de>
Subject Re: Standalone CouchDB Applications without Javascript
Date Wed, 14 Oct 2009 18:12:27 GMT
Chris Anderson schrieb:
> 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.
> 

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

Mime
View raw message