Render seems to provide a nice, clear definition for taking data (from a view view) and transforming (rendering) that data into something more useful.
Brad ________________________________ From: Christopher Lenz <cml...@gmx.de> To: dev@couchdb.apache.org Sent: Tuesday, January 13, 2009 11:06:30 AM Subject: Re: _show API (née _form) On 13.01.2009, at 08:27, Chris Anderson 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 I'm not a fan of "show" and "list". They're (a) not descriptive (too generic) and (b) not nicely pluralizable for use as a property name in the design docs. For example, "show" is a verb, and when you pluralize that (as Jan did later on this thread), things start sounding like showbiz :) The candidates I like so far are "render(ers)", "format(ters)", and "template(s)". I think those get pretty close to describing what the feature does. Cheers, -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/
