Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of jchris@gmail.com designates
 74.125.44.29 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=d1OyGw1EPiOOhMXl5wED/F5mnU9YPJ8HoXPAYiNu+rSN30p0MYHCZizJOhJMbe4RrE
         92wzQ10o1tzvijLfX325/Mt3nhQDobwKhQeyR+WFukWCq6BehbZV3cgBKnes6PrA9Dvj
         BzcunHwTPEzkaA4kilUcoFoq85swA17h4tQTg=
Message-ID: <e282921e0901121125j7dd6af26wb52f8206197dd803@mail.gmail.com>
Date: Mon, 12 Jan 2009 11:25:39 -0800
From: "Chris Anderson" <jchris@gmail.com>
To: dev@couchdb.apache.org
Subject: =?ISO-8859-1?Q?Re:_=5Fshow_API_(n=E9e_=5Fform)?=
In-Reply-To: <e2111bbb0901121109h4c0a49cwa08e8be990d394d0@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <e282921e0901091339o81e16b4w62c4a7917f38b452@mail.gmail.com>
	 <e2111bbb0901091351j5b86efk6971716cffd710a3@mail.gmail.com>
	 <64a10fff0901091401k191932b3k1963c2d07d7b2408@mail.gmail.com>
	 <e282921e0901091512r5b23543eqd0ae626d6cadce9f@mail.gmail.com>
	 <e2111bbb0901091526h6405f34bv38497708dfc283d8@mail.gmail.com>
	 <226d73360901120021n2334f477ve8deea2c5f2c456b@mail.gmail.com>
	 <e282921e0901121101g53d64513v26943c537ccc9887@mail.gmail.com>
	 <e2111bbb0901121109h4c0a49cwa08e8be990d394d0@mail.gmail.com>

On Mon, Jan 12, 2009 at 11:09 AM, Paul Davis
<paul.joseph.davis@gmail.com> wrote:
> On Mon, Jan 12, 2009 at 2:01 PM, Chris Anderson <jchris@gmail.com> wrote:
>> On Mon, Jan 12, 2009 at 12:21 AM, Ulises <ulises.cervino@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.

-- 
Chris Anderson
http://jchris.mfdz.com