Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of jchris@gmail.com designates
 209.85.221.21 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=c/SQo+X2nC/FdRIN1u0Tm+s0me/0ktYcKOlQRuJ97gWTc0g85xw0ZFD5EqjbWWmcNK
         mgsbTbX98/Pd0HYoWzNVHQlkVa4xgRxkkuMrRCCRogOPxh5C3jHWz+i5KUc25Jg/d3jZ
         KQov75hnttwaqTYbcrCxBlhJcZT+Zx8nS9yOc=
MIME-Version: 1.0
Sender: jchris@gmail.com
In-Reply-To: <20090208212554.GB11012@uk.tiscali.com>
References: <7d8fb2e90902060110me4c87f3q963083913f6e9666@mail.gmail.com>
	 <20090208212554.GB11012@uk.tiscali.com>
Date: Mon, 9 Feb 2009 11:30:30 -0800
Message-ID: <e282921e0902091130x196773fdkd7558f2abe7cf904@mail.gmail.com>
Subject: Re: Database Disruption From The Couch
From: Chris Anderson <jchris@apache.org>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Sun, Feb 8, 2009 at 1:25 PM, Brian Candler <B.Candler@pobox.com> wrote:
>
> (1) Personally, I'm not yet ready to move all view generation into the
> browser (Futon-like), i.e. where Javascript fetches the JSON, reformats as
> HTML, and submits back as JSON. In any case, supporting browsers without
> Javascript is still a useful capability.

The _show and _list features give you the capability to serve HTML or
other content types directly based on either doc or view queries. They
are a little lacking in documentation, but the test suite should be
enough to get your started.

>
> So for now at least, I still need a layer which will build HTML from a
> document, and allow document create/update via form POST.
>

If it doesn't work already, it'd be trivial to teach Couch to
understand norm HTML form POSTs, with some bare-bones conversion to a
JSON document (eg: each field is treated as a string, in a flat
namespace)


> (2) I need an application logic layer, which enforces business rules.
>

Validation functions can do a lot of this work. One thing that a
pure-Couch solution will discourage you from doing, that is considered
normal in Rails-style apps, is have one action modify or query lots of
documents or views. This is good for latency and cacheability, but may
make some applications harder to build.

> Put another way: document *storage/replication* and application *processing*
> of documents can (and in many cases probably should) remain separate.
> Couchapps remain an interesting idea however.

Yes. It really depends on your development model. One thing Couchapps
have that it's hard to get any other way is the extreme portability.


>
> This means that the application layer has to fetch the named document,
> *then* analyse what type it has, before dispatching to the appropriate
> controller/view logic.

The way _show and _list handle this is by having named functions, so
you'd have a url like

/db/_show/myapp/posts/post-id

or for authors

/db/_show/myapp/authors/author-id

of course asking for an error by calling something like
/db/_show/myapp/authors/post-id is a problem that Rails avoids due to
the Class / Table mapping.


>
> (4) Error handling: for Javascript user interfaces, if they are going to
> rely on the JSON response for failed 'model' validation, then the JSON error
> format needs to be carefully described and sufficiently detailled that the
> front-end can display meaningful messages to the user, e.g. which particular
> fields are invalid and why.

Agreed - I'm working on some validation helpers for Couchapp and my
Sofa blog. Part of what's up in the air here is where to draw the line
between the "standard library" of helpers included with CouchDB, and
what should be maintained in its own project.

> Map-reduce functions are also going to have to be robust to data of the
> 'wrong' type being present.

I always check my fields before using them.

if (doc.foo && doc.foo.bar ... etc)

Good questions. I hope some of what I've written helps.


-- 
Chris Anderson
http://jchris.mfdz.com