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 b.candler@pobox.com designates
 208.72.237.25 as permitted sender)
Date: Tue, 10 Feb 2009 21:09:28 +0000
From: Brian Candler <B.Candler@pobox.com>
To: Chris Anderson <jchris@apache.org>
Cc: user@couchdb.apache.org
Subject: Re: Database Disruption From The Couch
Message-ID: <20090210210928.GA19534@uk.tiscali.com>
References: <e282921e0902091130x196773fdkd7558f2abe7cf904@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e282921e0902091130x196773fdkd7558f2abe7cf904@mail.gmail.com>
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)

On Mon, Feb 09, 2009 at 11:30:30AM -0800, Chris Anderson 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.

Thanks. If I understand correctly, _show only acts on a single document? In
practice this may be less of a problem with couchdb than with a SQL-backed
system (where a single page often combines multiple models), but I can still
see cases where I want to combine a document with some related summary
information from a view. Maybe this could be done with iframes.

Similarly, AFAICT _list is also basic: a header, N rows from a single view,
a footer.

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

Again, I expect here that a single POST will only be able to update a single
document. But the Rails-type way of doing nested parameters maps well to
JSON:

   foo[bar]=hello       =>   {"foo":{"bar":"hello"}}

   foo[bar][]=hello&foo[bar][]=world

                        =>   {"foo":{"bar":["hello","world"]}}

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

Yes. I looked at Sofa's validation, and it basically just throws an error on
the first erroneous field it finds:

  if (type == 'post') {
    // post required fields
    require(author, "Posts must have an author.")
    require(newDoc.body, "Posts must have a body field")
    require(newDoc.html, "Posts must have an html field.");
    ... etc

    => {"forbidden":"Posts must have an author."}   etc

If there could be library support for building an errors structure which
maps individual tags in the source object to errors for that field, that
would be useful - not least because a well-defined structure could then be
interpreted by a corresponding library at the client side.

Cheers,

Brian.