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. Paul Davis > Again, the trade-off > would be longer paths for "more flexibility". > > -- > Chris Anderson > http://jchris.mfdz.com >
