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