Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jchris@gmail.com designates
 209.85.222.176 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=f3jNGyewZSmsauSUaxL/WyW4f3sm7e/z27on+Qy3c4Hi+KN4bIgkZTPuCbFkwUiqWC
         yqTgy/ROMU6uLFjiIikqVnDi6p5LDfCCk28p37V6rlT/+AIIJsfBocCdXX1mB/Z5Lmha
         2KBKxIGUtO4Q6x+VHP2fCY0QUzi6GAL669YWM=
MIME-Version: 1.0
Sender: jchris@gmail.com
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 12:06:12 -0700
Message-ID: <e282921e0910141206x67cbc43emc2fb2a5b6d3a399b@mail.gmail.com>
Subject: Re: Standalone CouchDB Applications without Javascript
From: Chris Anderson <jchris@apache.org>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 foc=
us
>>> has been standard-compliant, accessible web applications. One of the
>>> points
>>> that nag me the most are web applications that only work with javascrip=
t
>>> 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 thi=
s
>>> 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 bridg=
e
>>> that takes parameters sent, parses them in some way and constructs a
>>> new or changed CouchDB document.
>>>
>>> e.g. _id=3Dxxx&name=3DFoo&tag.1=3Dexample&tag.2=3Daccessible&sub.field=
=3Dbar
>>>
>>> would be converted to
>>> {
>>> =A0"_id" : "xxx",
>>> =A0"name": "Foo",
>>> =A0"tag" : ["example","accessible"],
>>> =A0"sub" : {
>>> =A0 "field" : "bar"
>>> =A0}
>>> }
>>>
>>> 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" encod=
ed
>>> 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 think the _update function can do this. It has access to the
userCtx, so it could redirect to the list of users's items, or
something. The point is you can programmatically control this, by
sending the correct headers in the response to an _update action.

I think this accomplishes your goals. If not, then I want to know more
about your goals, because the motivation (pure HTML) is noble.

>>
>> 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 f=
orm
> 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 n=
ot
> 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 co=
me
> 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
>


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