couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Anderson" <jch...@gmail.com>
Subject Re: _show API (née _form)
Date Sun, 11 Jan 2009 23:24:25 GMT
On Fri, Jan 9, 2009 at 3:43 PM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
> On Fri, Jan 9, 2009 at 1:38 PM, Dean Landolt <dean@deanlandolt.com> wrote:
>> 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
>
> Hmmm. Definitely fixes the limiting. I'll have to think on it to see
> if something comes to mind but it seems all right on first glimpse
>
>> 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).
>>
>

I'm gonna go ahead and commit the change that switches "_form" to
"_show" - we can continue to work on the details.

There's some good stuff coming up in this thread.

I like the idea of designdoc.show.docs and designdoc.show.views, maybe
I'll get that started while I'm in there.

I think the view function could have a rereduce like interface (one
function makes for much better performance under the query servers
implementation.)

function(row, head) {
  if (row) return "<li>"+row.key+"</li>";

  if (head) {
    return "<h1>"+head.row_count+" items</h1> <ul>";
  } else {
    return "</ul>";
  }
}

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

Mime
View raw message