On Tue, Jan 13, 2009 at 10:41 AM, Jan Lehnardt <j...@apache.org> wrote: > > On 13 Jan 2009, at 18:06, Christopher Lenz wrote: > >> 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. > > I'm cool with "render(ers)", my proposal is merely for the URL and design > doc structure. >
We should avoid adding a new section to the ini for this feature, so it will be implemented as an http_db_handler. I think this narrows the discussion a bit. Here's what I plan to implement: /db/_render/designname/funcname/docid or as a realistic example /myblog/_render/sofa/permalink-page/hello-blog-world and /db/_list/designname/viewname/funcname example /myblog/_list/sofa/recent-posts/feed I think we still haven't hit on a pair of names that feels just right. We should keep talking about better alternatives to _render and _list. I still prefer _show to _render, purely because it is shorter, but I don't want anyone to think I'm ramrodding my opinion here, so I'll switch the implementation to use _render. (Also "shows" is awkward in a design doc, but having ddoc.show.docs and ddoc.show.views makes it better.) I chose _list because aside from derived terms like _show_view or _render_list, and Damien's _vshow, it's been pretty much the only proposal. I'm sure there are better ones out there. I think the design doc structure will be relatively straightforward once we have the terms picked. -- Chris Anderson http://jchris.mfdz.com
