On Fri, Jan 9, 2009 at 3:43 PM, Paul Davis <paul.joseph.da...@gmail.com> wrote:
> On Fri, Jan 9, 2009 at 1:38 PM, Dean Landolt <d...@deanlandolt.com> wrote:
>> On Fri, Jan 9, 2009 at 6:26 PM, Paul Davis
>> <paul.joseph.da...@gmail.com>wrote:
>>
>>> On Fri, Jan 9, 2009 at 1:12 PM, Chris Anderson <jch...@gmail.com> wrote:
>>> > On Fri, Jan 9, 2009 at 2:01 PM, Dean Landolt <d...@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
