couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bradford Winfrey <bradswinf...@yahoo.com>
Subject Re: _show API (née _form)
Date Tue, 13 Jan 2009 01:41:30 GMT
Not that it matters but +1 for _render - I think that's the best definition thus far especially
when using "as" as the preposition to the format type.

Brad




________________________________
From: kowsik <kowsik@gmail.com>
To: dev@couchdb.apache.org
Sent: Monday, January 12, 2009 6:22:20 PM
Subject: Re: _show API (née _form)

_render?

GET /db/_render/sofa/recent-posts/as-html/

Reads nicely, IMHO.

K.

On Mon, Jan 12, 2009 at 4:05 PM, Chris Anderson <jchris@gmail.com> wrote:
>
> _view_show might even be better than _show_view, I think it's a little
> easier to look at and say.
>
> On Mon, Jan 12, 2009 at 4:03 PM, Damien Katz <damien@apache.org> wrote:
> > How about _dshow and _vshow? Hmmm, I liked those better until I saw them
> > typed out.
> >
> > -Damien
> >
> >
> > On Jan 12, 2009, at 6:55 PM, Chris Anderson wrote:
> >
> >> Is there a better url path than _show_view? Let's imagine a query
> >> (with descriptive names):
> >>
> >> Viewing the "sofa/resent-posts" view with show the function "as-html",
> >> this is option (B)
> >>
> >> B) GET /db/_show_view/sofa/as-html/recent-posts
> >>
> >> Maybe this would look better like:
> >>
> >> D) GET /db/_look/sofa/recent-posts/as-html
> >>
> >> except _look is kinda silly. I do think having readable urls, is a
> >> good way to relax.
> >>
> >> (D) translates as
> >>
> >> D) GET /db/_look/designname/myview/myshow
> >>
> >>
> >>
> >> On Mon, Jan 12, 2009 at 12:12 PM, Chris Anderson <jchris@gmail.com> wrote:
> >>>
> >>> On Mon, Jan 12, 2009 at 11:57 AM, Ulises <ulises.cervino@gmail.com>
> >>> wrote:
> >>>>>
> >>>>> A) GET /db/_show_view/mydesign/myview
> >>>>> B) GET /db/_show_view/mydesign/myshowfunc/myview
> >>>>> C) GET /db/_view/mydesign/myview?strartkey="foo"&show=myshowfunc
> >>>>
> >>>> Call me thick but C looks cleaner to me.
> >>>>
> >>>>> {
> >>>>> ...
> >>>>> "show" : {
> >>>>> "docs" : { ... },
> >>>>> "views" : {
> >>>>>  "myshowfunc" : "function(row, head) { ... }"
> >>>>> }
> >>>>> }
> >>>>
> >>>> how about including your show fns in show { } ?
> >>>
> >>> that's what's above
> >>>
> >>> show funcs for documents are at
> >>>
> >>> ddoc.show.docs
> >>>
> >>> and show funcs for views are at
> >>>
> >>> ddoc.show.views
> >>>
> >>>
> >>> I'm leaning B or C as well.
> >>>
> >>> My main reservation about C is what it will do to the internals.
> >>> Erlang actions that are scoped to a _private_path URL can be kept in
> >>> their own module and moved around via the config API. If we amke it an
> >>> options on regular views, we lose that freedom.
> >>>
> >>> Also, I do like the current URL scheme for document show funcs, partly
> >>> for the config reason, but also because I think
> >>>
> >>> GET /db/_show/mydesign/myshowfunc/docid
> >>>
> >>> is clearer than
> >>>
> >>> GET /db/docid?show=mydesign/myshowfun
> >>>
> >>>>
> >>>> {
> >>>> ...
> >>>> views: {
> >>>>  foo : { map : ... }
> >>>> },
> >>>> show: {
> >>>>  as_xml: function(...) { ... },
> >>>> }
> >>>> }
> >>>>
> >>>>> I'm leaning toward letting the user decide at query-time which view
to
> >>>>> render using which show-func, that is, options B or C.
> >>>>
> >>>> Well I thought that that was a given, flexibility so that users can
> >>>> define a couple of views, a couple of shows so that the combinations
> >>>> then are more useful.
> >>>>
> >>>> U
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Chris Anderson
> >>> http://jchris.mfdz.com
> >>>
> >>
> >>
> >>
> >> --
> >> Chris Anderson
> >> http://jchris.mfdz.com
> >
> >
>
>
>
> --
> Chris Anderson
> http://jchris.mfdz.com



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