couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Landolt <d...@deanlandolt.com>
Subject Re: Database Disruption From The Couch
Date Tue, 10 Feb 2009 21:26:21 GMT
On Tue, Feb 10, 2009 at 4:09 PM, Brian Candler <B.Candler@pobox.com> wrote:

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


Or you could just use a simple ajax call to pull in any additional data. I
can understand if you're looking to build the _show templates unobtrusively
by merging more than one doc or even views on the server (and I wish there
were a way to do that), but what's more *obtrusive *than 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"]}}


One doc update per POST seems pretty like a reasonable design constraint for
now -- if you want more, you can always go server side. But that's a pretty
sexy solution to form serialization I hadn't even considered. Is there some
way to also differentiate numerics? If so, that's *perfect*.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message