couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Anderson" <jch...@gmail.com>
Subject Re: _show API (née _form)
Date Mon, 12 Jan 2009 19:01:44 GMT
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. Again, the trade-off
would be longer paths for "more flexibility".

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

Mime
View raw message