+1 on render
The other thing I think we must think about, since we're discussing
naming here, is that I'd hate to have two different names one for
show_docs and one for show_views. From a user's point of view, I
wouldn't care really whether the info I'm looking at came from
_show_docs or _show_view.
_render is good IMO.
/db/_view/_render/as_foo
/db/docid/_render/as_foo <- (I must confess I haven't looked at the
whole _show feature in details so some things I say may be way off)
methinks.
2009/1/13 Bradford Winfrey <bradswinf...@yahoo.com>:
> 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 <kow...@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 <jch...@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 <dam...@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 <jch...@gmail.com> wrote:
>> >>>
>> >>> On Mon, Jan 12, 2009 at 11:57 AM, Ulises <ulises.cerv...@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
>
>
>
>
