On Mon, Jan 12, 2009 at 11:08 PM, 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) >
When we were discussing names on IRC, _render came up, but we liked _show better. I think mostly because it was shorter, but I think it also gets across the side-effect free nature of the functions pretty well (not that _render doesn't.) _render is basically fine... I do think I like _show and _list as a pair better, but I'm not set on them by any means. I think we'll need them to be different names, the question is whether they should be related, like _render_one and _render_many or if its fine to be a little more relaxed, like _show and _list. Something worth clearing up about my example. It would be bad form to have a function called "by-html" and I probably shouldn't have used it as an example. The better way to go would be a function called "blog-posts-by-date" which can satisfy client requests for "application/atom+xml", "application/rss+xml", and "text/html". This switching on Accept header is already implemented for doc show functions and demonstrated in the test suite. As far as paths go, there are various good reasons we should stick to the /db/_the_feature_name/... and not /db/.../_the_feature_name Best, Chris -- Chris Anderson http://jchris.mfdz.com
