couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bradford Winfrey <>
Subject Re: _show API (née _form)
Date Tue, 13 Jan 2009 17:21:41 GMT
Render seems to provide a nice, clear definition for taking data (from a view view) and transforming
(rendering) that data into something more useful.


From: Christopher Lenz <>
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 <> 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.

Christopher Lenz
  cmlenz at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message