couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Landolt <d...@deanlandolt.com>
Subject Re: _show API (née _form)
Date Fri, 09 Jan 2009 23:38:19 GMT
On Fri, Jan 9, 2009 at 6:26 PM, Paul Davis <paul.joseph.davis@gmail.com>wrote:

> On Fri, Jan 9, 2009 at 1:12 PM, Chris Anderson <jchris@gmail.com> wrote:
> > On Fri, Jan 9, 2009 at 2:01 PM, Dean Landolt <dean@deanlandolt.com>
> wrote:
> >> At the very least there should be a symmetry between the doc _show api
> and
> >> the view _show api, and
> >
> > Hows this for asymmetry? :)
> >
> > I did not mention one alternative URL address option. Just using the
> > standard view urls as they are, but adding show=true, like:
> >
> > GET /db/_view/mydesign/myview?startkey="b"&limit=10&show=true
> >
>
> I see where you're coming from, but I don't like this very much. My
> thoughts were something along the lines of being able to have multiple
> show functions per view. We could do the repeating the view code but
> that's really not good.
>
> >> while switching on passed in parameters is
> >> technically all the same, the internals of _show_view functions sound
> like
> >> they'll be complex enough with head/tail/row semantics.
> >>
> >
> > There's another question altogether, about how to structure the design
> document.
> >
>
> I was kinda assuming it'd be something like:
>
> {
>    "_id": "_design/foo",
>    "views": {
>        "bar": {
>            "map": "function(doc) {emit(doc._id, null);}"
>         }
>    },
>     "show": {
>        "docs": {
>            "xml": "function ... return doc as xml",
>            "doc_foo": "function ... return part of doc like ML guy wanted"
>        "views": {
>            "atom": {
>                "source": "bar",
>                "head": "function ... return head of atom stream",
>                "rows": "function .... etc",
>                "tail": "function .... miracle"
>            }
>        }
>    }
> }


That seems to work. And why not ?show=atom when hitting a view and
?show=doc_foo on a doc? The api would be a lot more consistent that way, and
it'd probably be the easiest option for new users to wrap their heads around
(direct correspondence between ?show=doc_foo and show.docs.doc_foo -- which
at least for me is the most important thing).

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