On Tue, Jan 13, 2009 at 2:08 AM, Ulises <ulises.cerv...@gmail.com> wrote:
> +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.
>
I agree with the sentiment, but I could see the compromises we made
with the / escaping stuff could make this hard to deconvolve in them
implementation. We could make it a fal back as in, it tries the
showing with the doc first then with the view, etc, but that's kinda
hackish.
Ideally yes, it'd just be one URL, but like I say, I can think of a
whole bunch of cases where it would be ambiguous.
And ambiguity is the devil in the details etc.
> 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
>>
>>
>>
>>
>
