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/
