From dev-return-6860-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Wed Oct 14 19:06:37 2009
Return-Path:
Delivered-To: apmail-couchdb-dev-archive@www.apache.org
Received: (qmail 83709 invoked from network); 14 Oct 2009 19:06:36 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
by minotaur.apache.org with SMTP; 14 Oct 2009 19:06:36 -0000
Received: (qmail 63238 invoked by uid 500); 14 Oct 2009 19:06:36 -0000
Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org
Received: (qmail 63180 invoked by uid 500); 14 Oct 2009 19:06:36 -0000
Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: dev@couchdb.apache.org
Delivered-To: mailing list dev@couchdb.apache.org
Received: (qmail 63170 invoked by uid 99); 14 Oct 2009 19:06:36 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Oct 2009 19:06:36 +0000
X-ASF-Spam-Status: No, hits=-2.6 required=5.0
tests=AWL,BAYES_00
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of jchris@gmail.com designates 209.85.222.176 as permitted sender)
Received: from [209.85.222.176] (HELO mail-pz0-f176.google.com) (209.85.222.176)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Oct 2009 19:06:32 +0000
Received: by pzk6 with SMTP id 6so144986pzk.29
for ; Wed, 14 Oct 2009 12:06:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:sender:received:in-reply-to
:references:date:x-google-sender-auth:message-id:subject:from:to
:content-type:content-transfer-encoding;
bh=gULRTXSw/+7HKYKSEJmb7lJlbJagRGtMm87/28iI1hc=;
b=albGRK2/leWi0/ZnffWmqVheoAZPuJOLU7MvXkyyg30vzveQbKdBJJdCnNrFc7NhmY
ds82tFCBJHSTakpsmHTMz+oc414ryyiChgxgknIvHCJNFoHfL3ADWlyIjpuUCnQ3gAU0
dWhYD+NwQFeuJ1sTc7nJw+XkP6QszXp9rF60k=
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
Received: by 10.142.7.39 with SMTP id 39mr660916wfg.113.1255547172661; Wed, 14
Oct 2009 12:06:12 -0700 (PDT)
In-Reply-To: <4AD6148B.5090701@gmx.de>
References: <4AD607EB.1020601@gmx.de>
<4AD6148B.5090701@gmx.de>
Date: Wed, 14 Oct 2009 12:06:12 -0700
X-Google-Sender-Auth: aadd82551f761384
Message-ID:
Subject: Re: Standalone CouchDB Applications without Javascript
From: Chris Anderson
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
wrote:
> Chris Anderson schrieb:
>>
>> On Wed, Oct 14, 2009 at 10:18 AM, Sven Helmberger
>> 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