On 13 Jan 2009, at 09:18, Chris Anderson wrote:
On Mon, Jan 12, 2009 at 11:38 PM, Paul Davis
<paul.joseph.da...@gmail.com> wrote:
On Tue, Jan 13, 2009 at 2:27 AM, Chris Anderson <jch...@gmail.com>
wrote:
On Mon, Jan 12, 2009 at 11:08 PM, Ulises
<ulises.cerv...@gmail.com> wrote:
+1 on render
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
But give us a couple words on why _the_doc_feature needs to be
different than _the_view_feature
Mostly because you use them for different things. If you're a client
library, it'd be nice to know that the view query options apply to
path A, and the doc query options apply to path B.
Also I think having different names will make it easier to work with
them, talk about them, etc... they are different functions, after all.
Even if we could squeeze both into the same name space, it doesn't
feel very relaxing.
I am repeating previous discussion and add a few new bits. I hope this
is an option that covers all things it affects.
How about:
{
"_id":"_design/mydesign",
"views":{"myview":"function()", ...},
"shows":{"myshow":"function()", ...},
"lists":{"mylist":"function()", ...}
}
Each "show"-function deals with all possible media types. There can be
multiple "show"-functions per design doc. Same for "list". "lists" can
only
operate on views in the same design document.
Call a view (for reference):
GET /db/_view/mydesign/myview?startkey="foo"
Call a show (on a doc):
GET /db/doc/_show/mydesign/myshow?rev=FCF5614
Call a list (on a view):
GET /db/_view/mydesign/mylist?startkey="foo"
If we want to keep the labels:
Call a show (on a doc):
GET /db/doc/_show/mydesign/_show/myshow?rev=FCF5614
Call a list (on a view):
GET /db/_view/mydesign/_list/mylist?startkey="foo"
Read: "shows" and "lists" are specializations of the resources they
transform, just like "_view/mydesign/viewname" is a specialization
of the "/db/" resource. Standard URL parameters should work as
usual. If "shows" and "lists" can receive extra parameters, they
can be used as well.
Am I missing anything?
--
Partially related:
I wonder if we should _-prefix the special fields in design docs, just
to make clear they are special. i.e.: "_views", "_shows", "_lists".
Please
keep this separate from the discussion above.
Cheers
Jan
--
