On Mon, Jan 12, 2009 at 2:25 PM, Chris Anderson <jch...@gmail.com> wrote:
> On Mon, Jan 12, 2009 at 11:09 AM, Paul Davis
> <paul.joseph.da...@gmail.com> wrote:
>> On Mon, Jan 12, 2009 at 2:01 PM, Chris Anderson <jch...@gmail.com> wrote:
>>> On Mon, Jan 12, 2009 at 12:21 AM, Ulises <ulises.cerv...@gmail.com> wrote:
>>>>> 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.
>>>>
>>>> FWIW, +1 on multiple shows per view. Following the MVC ideology, we
>>>> could say that the couchdb view is actually the model (the data) and
>>>> that the couchdb _show is the MVC view (the presentation). It only
>>>> makes sense (at least to me) to be able to present the same data in
>>>> many different ways, i.e. XML or JSON.
>>>>
>>>
>>> There's no limit on the ways you can present it, even with a single
>>> function. You can always switch on the clients Accept header, or on
>>> query parameters. This is really a question about how to organize the
>>> urls and the design docs. I do like your point about MVC.
>>>
>>> The nice thing about one function per view is that it allows for
>>> shorter paths, the downside is potentially more complex functions. I
>>> *think* it's straightforward that we should only allow views to be
>>> rendered by show functions defined in the same design doc as the view,
>>> but I could be convinced of the merits otherwise.
>>
>> Using show's to process views from other design docs sounds like more
>> code for the same level of usefulness. Also I think that it might
>> convey the wrong idea in terms of how to design applications etc. But
>> I could still be convinced otherwise.
>>
>
> OK lets assume that we don't want to do that (I think it's a bad idea too)
>
> So for view showing we'd have something like:
>
> A) GET /db/_show_view/mydesign/myview
>
> or
>
> B) GET /db/_show_view/mydesign/myshowfunc/myview
>
> or
>
> C) GET /db/_view/mydesign/myview?strartkey="foo"&show=myshowfunc
>
> and in the design doc:
>
> {
> ...
> "show" : {
> "docs" : { ... },
> "views" : {
> "myshowfunc" : "function(row, head) { ... }"
> }
> }
>
> In the case with one show function per view, we'd require that
> "myshowfunc" have the same name as "myview"...
>
> 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.
>
I'd agree. I think I'd vote for option C because it minimizes the URL
structure that people have to be aware of. Although, there might be
concerns in terms of what's being returned and what's expected in that
case. Ie, client libraries would have to have enough logic to figure
out the special show= query parameter was in effect and return a raw
body or some such.
Also, if C is the choice, should we make the _show for individual docs
become a url parameter as well for consistency?
Also, this could be messy, but could we do use _show for both docid
and view shows somehow? I see this getting messy with slash escaping
(or not escaping...)
Hmm. I started writing this email preferring C, but now I think I've
convinced myself that B would be better.
Paul Davis
> --
> Chris Anderson
> http://jchris.mfdz.com
>
