couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Anderson" <>
Subject Re: _show API (née _form)
Date Tue, 13 Jan 2009 07:27:57 GMT
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


Chris Anderson

View raw message