You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Sven Helmberger <sv...@gmx.de> on 2009/10/14 19:18:35 UTC
Standalone CouchDB Applications without Javascript
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)
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?)
How does this sound?
Any thoughts about it?
Regards,
Sven Helmberger
Re: Standalone CouchDB Applications without Javascript
Posted by Chris Anderson <jc...@apache.org>.
On Sat, Oct 24, 2009 at 12:57 AM, Sven Helmberger
<sv...@gmx.de> wrote:
> Chris Anderson schrieb:
>>
>> 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.
>>
>
> Yes, this basically seems to provide what I need, except for one thing: I
> can't send a PUT requests with pure HTML which means I can only create new
> or objects or completely overwrite them.
>
> I know it's not the way REST should work etc, but unfortunately browsers
> don't really care. So is there a possibility to at least optionally being
> allowed to POST to a _update function with docId instead of PUT?
>
You should be allowed to POST to an _update function with a docid as
well as PUT, heck you should be able to DELETE as well. I don't know
how I feel about GET as I'm not sure accidental side effects are
allowed.
OK. Checked the code and fixed it to be more flexible about verbs for _update:
http://svn.apache.org/viewvc?revision=829419&view=revision
The new code allows anything other than GET (which includes HEAD for us).
Sven, let me know if this solves your problem.
Chris
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: Standalone CouchDB Applications without Javascript
Posted by Sven Helmberger <sv...@gmx.de>.
Chris Anderson schrieb:
>
> 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.
>
Yes, this basically seems to provide what I need, except for one thing:
I can't send a PUT requests with pure HTML which means I can only create
new or objects or completely overwrite them.
I know it's not the way REST should work etc, but unfortunately browsers
don't really care. So is there a possibility to at least optionally
being allowed to POST to a _update function with docId instead of PUT?
Regards,
Sven Helmberger
Re: Standalone CouchDB Applications without Javascript
Posted by Chris Anderson <jc...@apache.org>.
On Wed, Oct 14, 2009 at 11:12 AM, Sven Helmberger
<sv...@gmx.de> wrote:
> Chris Anderson schrieb:
>>
>> On Wed, Oct 14, 2009 at 10:18 AM, Sven Helmberger
>> <sv...@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 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 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
>
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: Standalone CouchDB Applications without Javascript
Posted by Mikeal Rogers <mi...@gmail.com>.
Haha, I completely misread the subject. s/without/with.
-Mikeal
On Wed, Oct 14, 2009 at 11:17 AM, Sven Helmberger <sv...@gmx.de>wrote:
> Mikeal Rogers schrieb:
>
>> If you did the POST with XHR you could embed the redirect logic in the
>> client code rather than in the server.
>> -Mikeal
>>
>
> um.. That's the exact opposite of the goal to enable javascript less use.
>
> Regards,
> Sven Helmberger
>
Re: Standalone CouchDB Applications without Javascript
Posted by Sven Helmberger <sv...@gmx.de>.
Mikeal Rogers schrieb:
> If you did the POST with XHR you could embed the redirect logic in the
> client code rather than in the server.
> -Mikeal
um.. That's the exact opposite of the goal to enable javascript less use.
Regards,
Sven Helmberger
Re: Standalone CouchDB Applications without Javascript
Posted by Mikeal Rogers <mi...@gmail.com>.
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 <sv...@gmx.de>wrote:
> Chris Anderson schrieb:
>
> On Wed, Oct 14, 2009 at 10:18 AM, Sven Helmberger
>> <sv...@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
>
Re: Standalone CouchDB Applications without Javascript
Posted by Sven Helmberger <sv...@gmx.de>.
Chris Anderson schrieb:
> On Wed, Oct 14, 2009 at 10:18 AM, Sven Helmberger
> <sv...@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
Re: Standalone CouchDB Applications without Javascript
Posted by Chris Anderson <jc...@apache.org>.
On Wed, Oct 14, 2009 at 10:18 AM, Sven Helmberger
<sv...@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.
> How does this sound?
> Any thoughts about it?
>
> Regards,
> Sven Helmberger
>
--
Chris Anderson
http://jchrisa.net
http://couch.io