Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of mikeal.rogers@gmail.com
 designates 209.85.221.203 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=NA3pLxUakZTbAmJxGadjVeAa+/m4qlk5TKYs1ols5DWDR3rLNePucSmP09u5n3s0Qq
         4fWp1QBbqT/NmlRLaRo9wL0DdVruOqfNgLPnip3Q8OSWd81gyiDBs7cm7MV/u76AH4Qd
         v8hsW+LbJ+6g8DX0KFZzJH4mWbqMd4Qw8ckXI=
MIME-Version: 1.0
In-Reply-To: <4AD6148B.5090701@gmx.de>
References: <4AD607EB.1020601@gmx.de>
	 <e282921e0910141040h750d26eey334b0124692bee99@mail.gmail.com>
	 <4AD6148B.5090701@gmx.de>
Date: Wed, 14 Oct 2009 11:14:51 -0700
Message-ID: <30747dfa0910141114j67acc685sdbfe745cb8f0eb0a@mail.gmail.com>
Subject: Re: Standalone CouchDB Applications without Javascript
From: Mikeal Rogers <mikeal.rogers@gmail.com>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=000feaf10fcc9148690475e92352

--000feaf10fcc9148690475e92352
Content-Type: text/plain; charset=ISO-8859-1

If you did the POST with XHR you could embed the redirect logic in the
client code rather than in the server.
-Mikeal

On Wed, Oct 14, 2009 at 11:12 AM, Sven Helmberger <sven.helmberger@gmx.de>wrote:

> 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
>

--000feaf10fcc9148690475e92352--