On Tue, Jan 13, 2009 at 2:27 AM, Chris Anderson <jch...@gmail.com> wrote: > 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 >
But give us a couple words on why _the_doc_feature needs to be different than _the_view_feature > Best, > Chris > > -- > Chris Anderson > http://jchris.mfdz.com >
