You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Chris Anderson <jc...@apache.org> on 2009/01/09 22:39:07 UTC
_show API (née _form)
This is a summary of an IRC discussion prompted by Christopher Lenz
about the "forms" name and API.
The recently introduced _form feature is still rough. On IRC today we
managed to come up with a better name: _show. We like _show because it
makes clear that these functions are for formatting, and that they are
side-effect free, without overloading html's use of the word "form".
The API changes I'm describing haven't been implemented yet, but could
happen soon. The question about the _view show API is a bit more open,
as we don't have an implementation yet. The doc _show API has a subtle
question about whether to use path segments or query params for
function switching.
== The view _show API
The paradigm use case for view forms is generating Atom feeds from
views. By doing this in a CouchDB show function, you'll get row at a
time streaming and low memory overhead, while being able to service
even giant key ranges.
The first question is about user needs. It would be cleaner and easier
to develop a view-show API where each view has only one show function.
Within a function you can still switch on Accept-header (or query
string) so the same function can do both say Atom and RSS feeds.
Is there a strong reason to have more than one show function per view?
I think having more could lead to developer confusion (the inside of a
view show function will be a bit more complex than rereduce even --
head, tail, and row modes), and you can always switch on the query
string...
Assuming the one-form-pre-view constraint, here are some options for
the URL structure:
GET /db/_show_view/mydesign/myview
This would handle the same set of query parameters as the view api, so
you could use startkey, limit, skip etc.
GET /db/_show_view/mydesign/myview?startkey=["foo", "bar"]
Also the full set of query parameters would be available to the show
function so that devs could add eg ?nickname="J Chris A" if they
wanted to render a nickname into the view at runtime (and wreck
cacheability).
== Subtleties in the doc _show API
To run a document through a show function, the URL is:
GET /mydb/_show/mydesign/myshowfunc/docid
GET /mydb/_show/mydesign/othershowfunc/docid
Currently each design doc can have a set of show functions.
If we were to restrict the design doc to a single show function, we'd
have slightly shorter urls:
GET /mydb/_show/mydesign/docid
Should devs need to multiplex on user request, they could use query
string parameters (which are also available in the current
implementation) eg:
GET /mydb/_show/mydesign/docid?specifically=editdoc
so technically the two options have the same capabilities.
I find the current implementation a little easier to think about (it
results in smaller _show functions), and I think the URL length is not
a problem, really. Or rather that the additional length will usually
turn out to be descriptive of its purpose, so it's a net win.
--
Chris Anderson
http://jchris.mfdz.com
Re: _show API (née _form)
Posted by Chris Anderson <jc...@gmail.com>.
On Fri, Jan 9, 2009 at 3:43 PM, Paul Davis <pa...@gmail.com> wrote:
> On Fri, Jan 9, 2009 at 1:38 PM, Dean Landolt <de...@deanlandolt.com> wrote:
>> On Fri, Jan 9, 2009 at 6:26 PM, Paul Davis <pa...@gmail.com>wrote:
>>
>>> On Fri, Jan 9, 2009 at 1:12 PM, Chris Anderson <jc...@gmail.com> wrote:
>>> > On Fri, Jan 9, 2009 at 2:01 PM, Dean Landolt <de...@deanlandolt.com>
>>> wrote:
>>> >> At the very least there should be a symmetry between the doc _show api
>>> and
>>> >> the view _show api, and
>>> >
>>> > Hows this for asymmetry? :)
>>> >
>>> > I did not mention one alternative URL address option. Just using the
>>> > standard view urls as they are, but adding show=true, like:
>>> >
>>> > GET /db/_view/mydesign/myview?startkey="b"&limit=10&show=true
>>> >
>>>
>>> I see where you're coming from, but I don't like this very much. My
>>> thoughts were something along the lines of being able to have multiple
>>> show functions per view. We could do the repeating the view code but
>>> that's really not good.
>>>
>>> >> while switching on passed in parameters is
>>> >> technically all the same, the internals of _show_view functions sound
>>> like
>>> >> they'll be complex enough with head/tail/row semantics.
>>> >>
>>> >
>>> > There's another question altogether, about how to structure the design
>>> document.
>>> >
>>>
>>> I was kinda assuming it'd be something like:
>>>
>>> {
>>> "_id": "_design/foo",
>>> "views": {
>>> "bar": {
>>> "map": "function(doc) {emit(doc._id, null);}"
>>> }
>>> },
>>> "show": {
>>> "docs": {
>>> "xml": "function ... return doc as xml",
>>> "doc_foo": "function ... return part of doc like ML guy wanted"
>>> "views": {
>>> "atom": {
>>> "source": "bar",
>>> "head": "function ... return head of atom stream",
>>> "rows": "function .... etc",
>>> "tail": "function .... miracle"
>>> }
>>> }
>>> }
>>> }
>>
>>
>> That seems to work. And why not ?show=atom when hitting a view and
>> ?show=doc_foo on a doc? The api would be a lot more consistent that way, and
>
> Hmmm. Definitely fixes the limiting. I'll have to think on it to see
> if something comes to mind but it seems all right on first glimpse
>
>> it'd probably be the easiest option for new users to wrap their heads around
>> (direct correspondence between ?show=doc_foo and show.docs.doc_foo -- which
>> at least for me is the most important thing).
>>
>
I'm gonna go ahead and commit the change that switches "_form" to
"_show" - we can continue to work on the details.
There's some good stuff coming up in this thread.
I like the idea of designdoc.show.docs and designdoc.show.views, maybe
I'll get that started while I'm in there.
I think the view function could have a rereduce like interface (one
function makes for much better performance under the query servers
implementation.)
function(row, head) {
if (row) return "<li>"+row.key+"</li>";
if (head) {
return "<h1>"+head.row_count+" items</h1> <ul>";
} else {
return "</ul>";
}
}
--
Chris Anderson
http://jchris.mfdz.com
Re: _show API (née _form)
Posted by Paul Davis <pa...@gmail.com>.
On Fri, Jan 9, 2009 at 1:38 PM, Dean Landolt <de...@deanlandolt.com> wrote:
> On Fri, Jan 9, 2009 at 6:26 PM, Paul Davis <pa...@gmail.com>wrote:
>
>> On Fri, Jan 9, 2009 at 1:12 PM, Chris Anderson <jc...@gmail.com> wrote:
>> > On Fri, Jan 9, 2009 at 2:01 PM, Dean Landolt <de...@deanlandolt.com>
>> wrote:
>> >> At the very least there should be a symmetry between the doc _show api
>> and
>> >> the view _show api, and
>> >
>> > Hows this for asymmetry? :)
>> >
>> > I did not mention one alternative URL address option. Just using the
>> > standard view urls as they are, but adding show=true, like:
>> >
>> > GET /db/_view/mydesign/myview?startkey="b"&limit=10&show=true
>> >
>>
>> I see where you're coming from, but I don't like this very much. My
>> thoughts were something along the lines of being able to have multiple
>> show functions per view. We could do the repeating the view code but
>> that's really not good.
>>
>> >> while switching on passed in parameters is
>> >> technically all the same, the internals of _show_view functions sound
>> like
>> >> they'll be complex enough with head/tail/row semantics.
>> >>
>> >
>> > There's another question altogether, about how to structure the design
>> document.
>> >
>>
>> I was kinda assuming it'd be something like:
>>
>> {
>> "_id": "_design/foo",
>> "views": {
>> "bar": {
>> "map": "function(doc) {emit(doc._id, null);}"
>> }
>> },
>> "show": {
>> "docs": {
>> "xml": "function ... return doc as xml",
>> "doc_foo": "function ... return part of doc like ML guy wanted"
>> "views": {
>> "atom": {
>> "source": "bar",
>> "head": "function ... return head of atom stream",
>> "rows": "function .... etc",
>> "tail": "function .... miracle"
>> }
>> }
>> }
>> }
>
>
> That seems to work. And why not ?show=atom when hitting a view and
> ?show=doc_foo on a doc? The api would be a lot more consistent that way, and
Hmmm. Definitely fixes the limiting. I'll have to think on it to see
if something comes to mind but it seems all right on first glimpse
> it'd probably be the easiest option for new users to wrap their heads around
> (direct correspondence between ?show=doc_foo and show.docs.doc_foo -- which
> at least for me is the most important thing).
>
Re: _show API (née _form)
Posted by Dean Landolt <de...@deanlandolt.com>.
On Fri, Jan 9, 2009 at 6:26 PM, Paul Davis <pa...@gmail.com>wrote:
> On Fri, Jan 9, 2009 at 1:12 PM, Chris Anderson <jc...@gmail.com> wrote:
> > On Fri, Jan 9, 2009 at 2:01 PM, Dean Landolt <de...@deanlandolt.com>
> wrote:
> >> At the very least there should be a symmetry between the doc _show api
> and
> >> the view _show api, and
> >
> > Hows this for asymmetry? :)
> >
> > I did not mention one alternative URL address option. Just using the
> > standard view urls as they are, but adding show=true, like:
> >
> > GET /db/_view/mydesign/myview?startkey="b"&limit=10&show=true
> >
>
> I see where you're coming from, but I don't like this very much. My
> thoughts were something along the lines of being able to have multiple
> show functions per view. We could do the repeating the view code but
> that's really not good.
>
> >> while switching on passed in parameters is
> >> technically all the same, the internals of _show_view functions sound
> like
> >> they'll be complex enough with head/tail/row semantics.
> >>
> >
> > There's another question altogether, about how to structure the design
> document.
> >
>
> I was kinda assuming it'd be something like:
>
> {
> "_id": "_design/foo",
> "views": {
> "bar": {
> "map": "function(doc) {emit(doc._id, null);}"
> }
> },
> "show": {
> "docs": {
> "xml": "function ... return doc as xml",
> "doc_foo": "function ... return part of doc like ML guy wanted"
> "views": {
> "atom": {
> "source": "bar",
> "head": "function ... return head of atom stream",
> "rows": "function .... etc",
> "tail": "function .... miracle"
> }
> }
> }
> }
That seems to work. And why not ?show=atom when hitting a view and
?show=doc_foo on a doc? The api would be a lot more consistent that way, and
it'd probably be the easiest option for new users to wrap their heads around
(direct correspondence between ?show=doc_foo and show.docs.doc_foo -- which
at least for me is the most important thing).
Re: _show API (née _form)
Posted by Ulises <ul...@gmail.com>.
I read the options as
>> A) GET /db/_show_view/mydesign/myview
show me data from myview (how that data is presented I don't know)
>> B) GET /db/_show_view/mydesign/myshowfunc/myview
show me data in _myshowfunc_format_ from the set _myview_
>> C) GET /db/_view/mydesign/myview?strartkey="foo"&show=myshowfunc
show me data from _myview_ formatted as _myshowfunc_
Maybe I'm biased but C is more intuitive.
U
Re: _show API (née _form)
Posted by Paul Davis <pa...@gmail.com>.
On Mon, Jan 12, 2009 at 2:25 PM, Chris Anderson <jc...@gmail.com> wrote:
> On Mon, Jan 12, 2009 at 11:09 AM, Paul Davis
> <pa...@gmail.com> wrote:
>> On Mon, Jan 12, 2009 at 2:01 PM, Chris Anderson <jc...@gmail.com> wrote:
>>> On Mon, Jan 12, 2009 at 12:21 AM, Ulises <ul...@gmail.com> wrote:
>>>>> I see where you're coming from, but I don't like this very much. My
>>>>> thoughts were something along the lines of being able to have multiple
>>>>> show functions per view. We could do the repeating the view code but
>>>>> that's really not good.
>>>>
>>>> FWIW, +1 on multiple shows per view. Following the MVC ideology, we
>>>> could say that the couchdb view is actually the model (the data) and
>>>> that the couchdb _show is the MVC view (the presentation). It only
>>>> makes sense (at least to me) to be able to present the same data in
>>>> many different ways, i.e. XML or JSON.
>>>>
>>>
>>> There's no limit on the ways you can present it, even with a single
>>> function. You can always switch on the clients Accept header, or on
>>> query parameters. This is really a question about how to organize the
>>> urls and the design docs. I do like your point about MVC.
>>>
>>> The nice thing about one function per view is that it allows for
>>> shorter paths, the downside is potentially more complex functions. I
>>> *think* it's straightforward that we should only allow views to be
>>> rendered by show functions defined in the same design doc as the view,
>>> but I could be convinced of the merits otherwise.
>>
>> Using show's to process views from other design docs sounds like more
>> code for the same level of usefulness. Also I think that it might
>> convey the wrong idea in terms of how to design applications etc. But
>> I could still be convinced otherwise.
>>
>
> OK lets assume that we don't want to do that (I think it's a bad idea too)
>
> So for view showing we'd have something like:
>
> A) GET /db/_show_view/mydesign/myview
>
> or
>
> B) GET /db/_show_view/mydesign/myshowfunc/myview
>
> or
>
> C) GET /db/_view/mydesign/myview?strartkey="foo"&show=myshowfunc
>
> and in the design doc:
>
> {
> ...
> "show" : {
> "docs" : { ... },
> "views" : {
> "myshowfunc" : "function(row, head) { ... }"
> }
> }
>
> In the case with one show function per view, we'd require that
> "myshowfunc" have the same name as "myview"...
>
> I'm leaning toward letting the user decide at query-time which view to
> render using which show-func, that is, options B or C.
>
I'd agree. I think I'd vote for option C because it minimizes the URL
structure that people have to be aware of. Although, there might be
concerns in terms of what's being returned and what's expected in that
case. Ie, client libraries would have to have enough logic to figure
out the special show= query parameter was in effect and return a raw
body or some such.
Also, if C is the choice, should we make the _show for individual docs
become a url parameter as well for consistency?
Also, this could be messy, but could we do use _show for both docid
and view shows somehow? I see this getting messy with slash escaping
(or not escaping...)
Hmm. I started writing this email preferring C, but now I think I've
convinced myself that B would be better.
Paul Davis
> --
> Chris Anderson
> http://jchris.mfdz.com
>
Re: _show API (née _form)
Posted by Chris Anderson <jc...@gmail.com>.
On Mon, Jan 12, 2009 at 4:22 PM, kowsik <ko...@gmail.com> wrote:
> _render?
>
> GET /db/_render/sofa/recent-posts/as-html/
>
> Reads nicely, IMHO.
>
In principle, I'm not opposed to using _show for doc-funcs and
_something_else for view funcs, but I think it should be clear why one
word goes with docs and the other with views. Maybe something that
treats views as plural, like:
GET /db/_list/sofa/recent-posts/as-html?limit=10&descending=true
--
Chris Anderson
http://jchris.mfdz.com
Re: _show API (née _form)
Posted by Jan Lehnardt <ja...@apache.org>.
On 13 Jan 2009, at 15:11, Jan Lehnardt wrote:
>
> On 13 Jan 2009, at 09:18, Chris Anderson wrote:
>
>> On Mon, Jan 12, 2009 at 11:38 PM, Paul Davis
>> <pa...@gmail.com> wrote:
>>> On Tue, Jan 13, 2009 at 2:27 AM, Chris Anderson <jc...@gmail.com>
>>> wrote:
>>>> On Mon, Jan 12, 2009 at 11:08 PM, Ulises
>>>> <ul...@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"
>
Ignore this section in the previous mail and act as if I sent this:
Call a show (on a doc):
GET /db/doc/_show/mydesign/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
> --
>
>
Re: _show API (née _form)
Posted by Jan Lehnardt <ja...@apache.org>.
On 13 Jan 2009, at 09:18, Chris Anderson wrote:
> On Mon, Jan 12, 2009 at 11:38 PM, Paul Davis
> <pa...@gmail.com> wrote:
>> On Tue, Jan 13, 2009 at 2:27 AM, Chris Anderson <jc...@gmail.com>
>> wrote:
>>> On Mon, Jan 12, 2009 at 11:08 PM, Ulises
>>> <ul...@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
--
Re: _show API (née _form)
Posted by Paul Davis <pa...@gmail.com>.
On Tue, Jan 13, 2009 at 3:18 AM, Chris Anderson <jc...@gmail.com> wrote:
> On Mon, Jan 12, 2009 at 11:38 PM, Paul Davis
> <pa...@gmail.com> wrote:
>> On Tue, Jan 13, 2009 at 2:27 AM, Chris Anderson <jc...@gmail.com> wrote:
>>> On Mon, Jan 12, 2009 at 11:08 PM, Ulises <ul...@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
>>>
>>
>> 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.
>
Definitely good points. I was mostly concerned about the slash
escaping ambiguity and you make a good argument even without
implementation references. I'm sold.
> --
> Chris Anderson
> http://jchris.mfdz.com
>
Re: _show API (née _form)
Posted by Chris Anderson <jc...@gmail.com>.
On Mon, Jan 12, 2009 at 11:38 PM, Paul Davis
<pa...@gmail.com> wrote:
> On Tue, Jan 13, 2009 at 2:27 AM, Chris Anderson <jc...@gmail.com> wrote:
>> On Mon, Jan 12, 2009 at 11:08 PM, Ulises <ul...@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
>>
>
> 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.
--
Chris Anderson
http://jchris.mfdz.com
Re: _show API (née _form)
Posted by Paul Davis <pa...@gmail.com>.
On Tue, Jan 13, 2009 at 2:27 AM, Chris Anderson <jc...@gmail.com> wrote:
> On Mon, Jan 12, 2009 at 11:08 PM, Ulises <ul...@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
>
But give us a couple words on why _the_doc_feature needs to be
different than _the_view_feature
> Best,
> Chris
>
> --
> Chris Anderson
> http://jchris.mfdz.com
>
Re: _show API (née _form)
Posted by Dean Landolt <de...@deanlandolt.com>.
On Tue, Jan 13, 2009 at 12:21 PM, Bradford Winfrey
<br...@yahoo.com>wrote:
> Render seems to provide a nice, clear definition for taking data (from a
> view view) and transforming (rendering) that data into something more
> useful.
>
> Brad
It also makes sense when taking data (from a doc) and transforming -- but I
understand the concern about differentiating between a doc and a view. From
a user perspective, depending on what you're rendering you'll have a
different set query params to pass in (startkey/endkey makes no sense on
render_doc).
Something like _render_doc or _render_view would work nicely for me (I just
want the feature -- I don't care too much of the name). But if most people
want just one name, wouldn't there already be enough data in the url itself
to be demonstrative of the context that you're rendering in?
I imagine that...
/db/_render/mydesign/myview
...could be ambiguous against...
/db/_render/mydoc/mydesign/myview
To break this ambiguity you could require a full path to design doc so it'd
be:
/db/_render/<doc_id>/<view>
...or...
/db/_render/_design/mydesign/myview
...and the same for docs, essentially...
/db/_render/mydoc/mydesign/myview
Would this satisfy all cases?
Re: _show API (née _form)
Posted by Bradford Winfrey <br...@yahoo.com>.
Render seems to provide a nice, clear definition for taking data (from a view view) and transforming (rendering) that data into something more useful.
Brad
________________________________
From: Christopher Lenz <cm...@gmx.de>
To: dev@couchdb.apache.org
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 <ul...@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/
Re: _show API (née _form)
Posted by Chris Anderson <jc...@gmail.com>.
On Tue, Jan 13, 2009 at 10:41 AM, Jan Lehnardt <ja...@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
Re: _show API (née _form)
Posted by Jan Lehnardt <ja...@apache.org>.
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.
Cheers
Jan
--
Re: _show API (née _form)
Posted by Christopher Lenz <cm...@gmx.de>.
On 13.01.2009, at 08:27, Chris Anderson wrote:
> On Mon, Jan 12, 2009 at 11:08 PM, Ulises <ul...@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/
Re: _show API (née _form)
Posted by Chris Anderson <jc...@gmail.com>.
On Mon, Jan 12, 2009 at 11:08 PM, Ulises <ul...@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
Best,
Chris
--
Chris Anderson
http://jchris.mfdz.com
Re: _show API (née _form)
Posted by Paul Davis <pa...@gmail.com>.
On Tue, Jan 13, 2009 at 2:08 AM, Ulises <ul...@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)
>
> methinks.
>
I agree with the sentiment, but I could see the compromises we made
with the / escaping stuff could make this hard to deconvolve in them
implementation. We could make it a fal back as in, it tries the
showing with the doc first then with the view, etc, but that's kinda
hackish.
Ideally yes, it'd just be one URL, but like I say, I can think of a
whole bunch of cases where it would be ambiguous.
And ambiguity is the devil in the details etc.
> 2009/1/13 Bradford Winfrey <br...@yahoo.com>:
>> Not that it matters but +1 for _render - I think that's the best definition thus far especially when using "as" as the preposition to the format type.
>>
>> Brad
>>
>>
>>
>>
>> ________________________________
>> From: kowsik <ko...@gmail.com>
>> To: dev@couchdb.apache.org
>> Sent: Monday, January 12, 2009 6:22:20 PM
>> Subject: Re: _show API (née _form)
>>
>> _render?
>>
>> GET /db/_render/sofa/recent-posts/as-html/
>>
>> Reads nicely, IMHO.
>>
>> K.
>>
>> On Mon, Jan 12, 2009 at 4:05 PM, Chris Anderson <jc...@gmail.com> wrote:
>>>
>>> _view_show might even be better than _show_view, I think it's a little
>>> easier to look at and say.
>>>
>>> On Mon, Jan 12, 2009 at 4:03 PM, Damien Katz <da...@apache.org> wrote:
>>> > How about _dshow and _vshow? Hmmm, I liked those better until I saw them
>>> > typed out.
>>> >
>>> > -Damien
>>> >
>>> >
>>> > On Jan 12, 2009, at 6:55 PM, Chris Anderson wrote:
>>> >
>>> >> Is there a better url path than _show_view? Let's imagine a query
>>> >> (with descriptive names):
>>> >>
>>> >> Viewing the "sofa/resent-posts" view with show the function "as-html",
>>> >> this is option (B)
>>> >>
>>> >> B) GET /db/_show_view/sofa/as-html/recent-posts
>>> >>
>>> >> Maybe this would look better like:
>>> >>
>>> >> D) GET /db/_look/sofa/recent-posts/as-html
>>> >>
>>> >> except _look is kinda silly. I do think having readable urls, is a
>>> >> good way to relax.
>>> >>
>>> >> (D) translates as
>>> >>
>>> >> D) GET /db/_look/designname/myview/myshow
>>> >>
>>> >>
>>> >>
>>> >> On Mon, Jan 12, 2009 at 12:12 PM, Chris Anderson <jc...@gmail.com> wrote:
>>> >>>
>>> >>> On Mon, Jan 12, 2009 at 11:57 AM, Ulises <ul...@gmail.com>
>>> >>> wrote:
>>> >>>>>
>>> >>>>> A) GET /db/_show_view/mydesign/myview
>>> >>>>> B) GET /db/_show_view/mydesign/myshowfunc/myview
>>> >>>>> C) GET /db/_view/mydesign/myview?strartkey="foo"&show=myshowfunc
>>> >>>>
>>> >>>> Call me thick but C looks cleaner to me.
>>> >>>>
>>> >>>>> {
>>> >>>>> ...
>>> >>>>> "show" : {
>>> >>>>> "docs" : { ... },
>>> >>>>> "views" : {
>>> >>>>> "myshowfunc" : "function(row, head) { ... }"
>>> >>>>> }
>>> >>>>> }
>>> >>>>
>>> >>>> how about including your show fns in show { } ?
>>> >>>
>>> >>> that's what's above
>>> >>>
>>> >>> show funcs for documents are at
>>> >>>
>>> >>> ddoc.show.docs
>>> >>>
>>> >>> and show funcs for views are at
>>> >>>
>>> >>> ddoc.show.views
>>> >>>
>>> >>>
>>> >>> I'm leaning B or C as well.
>>> >>>
>>> >>> My main reservation about C is what it will do to the internals.
>>> >>> Erlang actions that are scoped to a _private_path URL can be kept in
>>> >>> their own module and moved around via the config API. If we amke it an
>>> >>> options on regular views, we lose that freedom.
>>> >>>
>>> >>> Also, I do like the current URL scheme for document show funcs, partly
>>> >>> for the config reason, but also because I think
>>> >>>
>>> >>> GET /db/_show/mydesign/myshowfunc/docid
>>> >>>
>>> >>> is clearer than
>>> >>>
>>> >>> GET /db/docid?show=mydesign/myshowfun
>>> >>>
>>> >>>>
>>> >>>> {
>>> >>>> ...
>>> >>>> views: {
>>> >>>> foo : { map : ... }
>>> >>>> },
>>> >>>> show: {
>>> >>>> as_xml: function(...) { ... },
>>> >>>> }
>>> >>>> }
>>> >>>>
>>> >>>>> I'm leaning toward letting the user decide at query-time which view to
>>> >>>>> render using which show-func, that is, options B or C.
>>> >>>>
>>> >>>> Well I thought that that was a given, flexibility so that users can
>>> >>>> define a couple of views, a couple of shows so that the combinations
>>> >>>> then are more useful.
>>> >>>>
>>> >>>> U
>>> >>>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Chris Anderson
>>> >>> http://jchris.mfdz.com
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Chris Anderson
>>> >> http://jchris.mfdz.com
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Chris Anderson
>>> http://jchris.mfdz.com
>>
>>
>>
>>
>
Re: _show API (née _form)
Posted by Ulises <ul...@gmail.com>.
+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)
methinks.
2009/1/13 Bradford Winfrey <br...@yahoo.com>:
> Not that it matters but +1 for _render - I think that's the best definition thus far especially when using "as" as the preposition to the format type.
>
> Brad
>
>
>
>
> ________________________________
> From: kowsik <ko...@gmail.com>
> To: dev@couchdb.apache.org
> Sent: Monday, January 12, 2009 6:22:20 PM
> Subject: Re: _show API (née _form)
>
> _render?
>
> GET /db/_render/sofa/recent-posts/as-html/
>
> Reads nicely, IMHO.
>
> K.
>
> On Mon, Jan 12, 2009 at 4:05 PM, Chris Anderson <jc...@gmail.com> wrote:
>>
>> _view_show might even be better than _show_view, I think it's a little
>> easier to look at and say.
>>
>> On Mon, Jan 12, 2009 at 4:03 PM, Damien Katz <da...@apache.org> wrote:
>> > How about _dshow and _vshow? Hmmm, I liked those better until I saw them
>> > typed out.
>> >
>> > -Damien
>> >
>> >
>> > On Jan 12, 2009, at 6:55 PM, Chris Anderson wrote:
>> >
>> >> Is there a better url path than _show_view? Let's imagine a query
>> >> (with descriptive names):
>> >>
>> >> Viewing the "sofa/resent-posts" view with show the function "as-html",
>> >> this is option (B)
>> >>
>> >> B) GET /db/_show_view/sofa/as-html/recent-posts
>> >>
>> >> Maybe this would look better like:
>> >>
>> >> D) GET /db/_look/sofa/recent-posts/as-html
>> >>
>> >> except _look is kinda silly. I do think having readable urls, is a
>> >> good way to relax.
>> >>
>> >> (D) translates as
>> >>
>> >> D) GET /db/_look/designname/myview/myshow
>> >>
>> >>
>> >>
>> >> On Mon, Jan 12, 2009 at 12:12 PM, Chris Anderson <jc...@gmail.com> wrote:
>> >>>
>> >>> On Mon, Jan 12, 2009 at 11:57 AM, Ulises <ul...@gmail.com>
>> >>> wrote:
>> >>>>>
>> >>>>> A) GET /db/_show_view/mydesign/myview
>> >>>>> B) GET /db/_show_view/mydesign/myshowfunc/myview
>> >>>>> C) GET /db/_view/mydesign/myview?strartkey="foo"&show=myshowfunc
>> >>>>
>> >>>> Call me thick but C looks cleaner to me.
>> >>>>
>> >>>>> {
>> >>>>> ...
>> >>>>> "show" : {
>> >>>>> "docs" : { ... },
>> >>>>> "views" : {
>> >>>>> "myshowfunc" : "function(row, head) { ... }"
>> >>>>> }
>> >>>>> }
>> >>>>
>> >>>> how about including your show fns in show { } ?
>> >>>
>> >>> that's what's above
>> >>>
>> >>> show funcs for documents are at
>> >>>
>> >>> ddoc.show.docs
>> >>>
>> >>> and show funcs for views are at
>> >>>
>> >>> ddoc.show.views
>> >>>
>> >>>
>> >>> I'm leaning B or C as well.
>> >>>
>> >>> My main reservation about C is what it will do to the internals.
>> >>> Erlang actions that are scoped to a _private_path URL can be kept in
>> >>> their own module and moved around via the config API. If we amke it an
>> >>> options on regular views, we lose that freedom.
>> >>>
>> >>> Also, I do like the current URL scheme for document show funcs, partly
>> >>> for the config reason, but also because I think
>> >>>
>> >>> GET /db/_show/mydesign/myshowfunc/docid
>> >>>
>> >>> is clearer than
>> >>>
>> >>> GET /db/docid?show=mydesign/myshowfun
>> >>>
>> >>>>
>> >>>> {
>> >>>> ...
>> >>>> views: {
>> >>>> foo : { map : ... }
>> >>>> },
>> >>>> show: {
>> >>>> as_xml: function(...) { ... },
>> >>>> }
>> >>>> }
>> >>>>
>> >>>>> I'm leaning toward letting the user decide at query-time which view to
>> >>>>> render using which show-func, that is, options B or C.
>> >>>>
>> >>>> Well I thought that that was a given, flexibility so that users can
>> >>>> define a couple of views, a couple of shows so that the combinations
>> >>>> then are more useful.
>> >>>>
>> >>>> U
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Chris Anderson
>> >>> http://jchris.mfdz.com
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Chris Anderson
>> >> http://jchris.mfdz.com
>> >
>> >
>>
>>
>>
>> --
>> Chris Anderson
>> http://jchris.mfdz.com
>
>
>
>
Re: _show API (née _form)
Posted by Bradford Winfrey <br...@yahoo.com>.
Not that it matters but +1 for _render - I think that's the best definition thus far especially when using "as" as the preposition to the format type.
Brad
________________________________
From: kowsik <ko...@gmail.com>
To: dev@couchdb.apache.org
Sent: Monday, January 12, 2009 6:22:20 PM
Subject: Re: _show API (née _form)
_render?
GET /db/_render/sofa/recent-posts/as-html/
Reads nicely, IMHO.
K.
On Mon, Jan 12, 2009 at 4:05 PM, Chris Anderson <jc...@gmail.com> wrote:
>
> _view_show might even be better than _show_view, I think it's a little
> easier to look at and say.
>
> On Mon, Jan 12, 2009 at 4:03 PM, Damien Katz <da...@apache.org> wrote:
> > How about _dshow and _vshow? Hmmm, I liked those better until I saw them
> > typed out.
> >
> > -Damien
> >
> >
> > On Jan 12, 2009, at 6:55 PM, Chris Anderson wrote:
> >
> >> Is there a better url path than _show_view? Let's imagine a query
> >> (with descriptive names):
> >>
> >> Viewing the "sofa/resent-posts" view with show the function "as-html",
> >> this is option (B)
> >>
> >> B) GET /db/_show_view/sofa/as-html/recent-posts
> >>
> >> Maybe this would look better like:
> >>
> >> D) GET /db/_look/sofa/recent-posts/as-html
> >>
> >> except _look is kinda silly. I do think having readable urls, is a
> >> good way to relax.
> >>
> >> (D) translates as
> >>
> >> D) GET /db/_look/designname/myview/myshow
> >>
> >>
> >>
> >> On Mon, Jan 12, 2009 at 12:12 PM, Chris Anderson <jc...@gmail.com> wrote:
> >>>
> >>> On Mon, Jan 12, 2009 at 11:57 AM, Ulises <ul...@gmail.com>
> >>> wrote:
> >>>>>
> >>>>> A) GET /db/_show_view/mydesign/myview
> >>>>> B) GET /db/_show_view/mydesign/myshowfunc/myview
> >>>>> C) GET /db/_view/mydesign/myview?strartkey="foo"&show=myshowfunc
> >>>>
> >>>> Call me thick but C looks cleaner to me.
> >>>>
> >>>>> {
> >>>>> ...
> >>>>> "show" : {
> >>>>> "docs" : { ... },
> >>>>> "views" : {
> >>>>> "myshowfunc" : "function(row, head) { ... }"
> >>>>> }
> >>>>> }
> >>>>
> >>>> how about including your show fns in show { } ?
> >>>
> >>> that's what's above
> >>>
> >>> show funcs for documents are at
> >>>
> >>> ddoc.show.docs
> >>>
> >>> and show funcs for views are at
> >>>
> >>> ddoc.show.views
> >>>
> >>>
> >>> I'm leaning B or C as well.
> >>>
> >>> My main reservation about C is what it will do to the internals.
> >>> Erlang actions that are scoped to a _private_path URL can be kept in
> >>> their own module and moved around via the config API. If we amke it an
> >>> options on regular views, we lose that freedom.
> >>>
> >>> Also, I do like the current URL scheme for document show funcs, partly
> >>> for the config reason, but also because I think
> >>>
> >>> GET /db/_show/mydesign/myshowfunc/docid
> >>>
> >>> is clearer than
> >>>
> >>> GET /db/docid?show=mydesign/myshowfun
> >>>
> >>>>
> >>>> {
> >>>> ...
> >>>> views: {
> >>>> foo : { map : ... }
> >>>> },
> >>>> show: {
> >>>> as_xml: function(...) { ... },
> >>>> }
> >>>> }
> >>>>
> >>>>> I'm leaning toward letting the user decide at query-time which view to
> >>>>> render using which show-func, that is, options B or C.
> >>>>
> >>>> Well I thought that that was a given, flexibility so that users can
> >>>> define a couple of views, a couple of shows so that the combinations
> >>>> then are more useful.
> >>>>
> >>>> U
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Chris Anderson
> >>> http://jchris.mfdz.com
> >>>
> >>
> >>
> >>
> >> --
> >> Chris Anderson
> >> http://jchris.mfdz.com
> >
> >
>
>
>
> --
> Chris Anderson
> http://jchris.mfdz.com
Re: _show API (née _form)
Posted by kowsik <ko...@gmail.com>.
_render?
GET /db/_render/sofa/recent-posts/as-html/
Reads nicely, IMHO.
K.
On Mon, Jan 12, 2009 at 4:05 PM, Chris Anderson <jc...@gmail.com> wrote:
>
> _view_show might even be better than _show_view, I think it's a little
> easier to look at and say.
>
> On Mon, Jan 12, 2009 at 4:03 PM, Damien Katz <da...@apache.org> wrote:
> > How about _dshow and _vshow? Hmmm, I liked those better until I saw them
> > typed out.
> >
> > -Damien
> >
> >
> > On Jan 12, 2009, at 6:55 PM, Chris Anderson wrote:
> >
> >> Is there a better url path than _show_view? Let's imagine a query
> >> (with descriptive names):
> >>
> >> Viewing the "sofa/resent-posts" view with show the function "as-html",
> >> this is option (B)
> >>
> >> B) GET /db/_show_view/sofa/as-html/recent-posts
> >>
> >> Maybe this would look better like:
> >>
> >> D) GET /db/_look/sofa/recent-posts/as-html
> >>
> >> except _look is kinda silly. I do think having readable urls, is a
> >> good way to relax.
> >>
> >> (D) translates as
> >>
> >> D) GET /db/_look/designname/myview/myshow
> >>
> >>
> >>
> >> On Mon, Jan 12, 2009 at 12:12 PM, Chris Anderson <jc...@gmail.com> wrote:
> >>>
> >>> On Mon, Jan 12, 2009 at 11:57 AM, Ulises <ul...@gmail.com>
> >>> wrote:
> >>>>>
> >>>>> A) GET /db/_show_view/mydesign/myview
> >>>>> B) GET /db/_show_view/mydesign/myshowfunc/myview
> >>>>> C) GET /db/_view/mydesign/myview?strartkey="foo"&show=myshowfunc
> >>>>
> >>>> Call me thick but C looks cleaner to me.
> >>>>
> >>>>> {
> >>>>> ...
> >>>>> "show" : {
> >>>>> "docs" : { ... },
> >>>>> "views" : {
> >>>>> "myshowfunc" : "function(row, head) { ... }"
> >>>>> }
> >>>>> }
> >>>>
> >>>> how about including your show fns in show { } ?
> >>>
> >>> that's what's above
> >>>
> >>> show funcs for documents are at
> >>>
> >>> ddoc.show.docs
> >>>
> >>> and show funcs for views are at
> >>>
> >>> ddoc.show.views
> >>>
> >>>
> >>> I'm leaning B or C as well.
> >>>
> >>> My main reservation about C is what it will do to the internals.
> >>> Erlang actions that are scoped to a _private_path URL can be kept in
> >>> their own module and moved around via the config API. If we amke it an
> >>> options on regular views, we lose that freedom.
> >>>
> >>> Also, I do like the current URL scheme for document show funcs, partly
> >>> for the config reason, but also because I think
> >>>
> >>> GET /db/_show/mydesign/myshowfunc/docid
> >>>
> >>> is clearer than
> >>>
> >>> GET /db/docid?show=mydesign/myshowfun
> >>>
> >>>>
> >>>> {
> >>>> ...
> >>>> views: {
> >>>> foo : { map : ... }
> >>>> },
> >>>> show: {
> >>>> as_xml: function(...) { ... },
> >>>> }
> >>>> }
> >>>>
> >>>>> I'm leaning toward letting the user decide at query-time which view to
> >>>>> render using which show-func, that is, options B or C.
> >>>>
> >>>> Well I thought that that was a given, flexibility so that users can
> >>>> define a couple of views, a couple of shows so that the combinations
> >>>> then are more useful.
> >>>>
> >>>> U
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Chris Anderson
> >>> http://jchris.mfdz.com
> >>>
> >>
> >>
> >>
> >> --
> >> Chris Anderson
> >> http://jchris.mfdz.com
> >
> >
>
>
>
> --
> Chris Anderson
> http://jchris.mfdz.com
Re: _show API (née _form)
Posted by Chris Anderson <jc...@gmail.com>.
_view_show might even be better than _show_view, I think it's a little
easier to look at and say.
On Mon, Jan 12, 2009 at 4:03 PM, Damien Katz <da...@apache.org> wrote:
> How about _dshow and _vshow? Hmmm, I liked those better until I saw them
> typed out.
>
> -Damien
>
>
> On Jan 12, 2009, at 6:55 PM, Chris Anderson wrote:
>
>> Is there a better url path than _show_view? Let's imagine a query
>> (with descriptive names):
>>
>> Viewing the "sofa/resent-posts" view with show the function "as-html",
>> this is option (B)
>>
>> B) GET /db/_show_view/sofa/as-html/recent-posts
>>
>> Maybe this would look better like:
>>
>> D) GET /db/_look/sofa/recent-posts/as-html
>>
>> except _look is kinda silly. I do think having readable urls, is a
>> good way to relax.
>>
>> (D) translates as
>>
>> D) GET /db/_look/designname/myview/myshow
>>
>>
>>
>> On Mon, Jan 12, 2009 at 12:12 PM, Chris Anderson <jc...@gmail.com> wrote:
>>>
>>> On Mon, Jan 12, 2009 at 11:57 AM, Ulises <ul...@gmail.com>
>>> wrote:
>>>>>
>>>>> A) GET /db/_show_view/mydesign/myview
>>>>> B) GET /db/_show_view/mydesign/myshowfunc/myview
>>>>> C) GET /db/_view/mydesign/myview?strartkey="foo"&show=myshowfunc
>>>>
>>>> Call me thick but C looks cleaner to me.
>>>>
>>>>> {
>>>>> ...
>>>>> "show" : {
>>>>> "docs" : { ... },
>>>>> "views" : {
>>>>> "myshowfunc" : "function(row, head) { ... }"
>>>>> }
>>>>> }
>>>>
>>>> how about including your show fns in show { } ?
>>>
>>> that's what's above
>>>
>>> show funcs for documents are at
>>>
>>> ddoc.show.docs
>>>
>>> and show funcs for views are at
>>>
>>> ddoc.show.views
>>>
>>>
>>> I'm leaning B or C as well.
>>>
>>> My main reservation about C is what it will do to the internals.
>>> Erlang actions that are scoped to a _private_path URL can be kept in
>>> their own module and moved around via the config API. If we amke it an
>>> options on regular views, we lose that freedom.
>>>
>>> Also, I do like the current URL scheme for document show funcs, partly
>>> for the config reason, but also because I think
>>>
>>> GET /db/_show/mydesign/myshowfunc/docid
>>>
>>> is clearer than
>>>
>>> GET /db/docid?show=mydesign/myshowfun
>>>
>>>>
>>>> {
>>>> ...
>>>> views: {
>>>> foo : { map : ... }
>>>> },
>>>> show: {
>>>> as_xml: function(...) { ... },
>>>> }
>>>> }
>>>>
>>>>> I'm leaning toward letting the user decide at query-time which view to
>>>>> render using which show-func, that is, options B or C.
>>>>
>>>> Well I thought that that was a given, flexibility so that users can
>>>> define a couple of views, a couple of shows so that the combinations
>>>> then are more useful.
>>>>
>>>> U
>>>>
>>>
>>>
>>>
>>> --
>>> Chris Anderson
>>> http://jchris.mfdz.com
>>>
>>
>>
>>
>> --
>> Chris Anderson
>> http://jchris.mfdz.com
>
>
--
Chris Anderson
http://jchris.mfdz.com
Re: _show API (née _form)
Posted by Damien Katz <da...@apache.org>.
How about _dshow and _vshow? Hmmm, I liked those better until I saw
them typed out.
-Damien
On Jan 12, 2009, at 6:55 PM, Chris Anderson wrote:
> Is there a better url path than _show_view? Let's imagine a query
> (with descriptive names):
>
> Viewing the "sofa/resent-posts" view with show the function "as-html",
> this is option (B)
>
> B) GET /db/_show_view/sofa/as-html/recent-posts
>
> Maybe this would look better like:
>
> D) GET /db/_look/sofa/recent-posts/as-html
>
> except _look is kinda silly. I do think having readable urls, is a
> good way to relax.
>
> (D) translates as
>
> D) GET /db/_look/designname/myview/myshow
>
>
>
> On Mon, Jan 12, 2009 at 12:12 PM, Chris Anderson <jc...@gmail.com>
> wrote:
>> On Mon, Jan 12, 2009 at 11:57 AM, Ulises <ul...@gmail.com>
>> wrote:
>>>> A) GET /db/_show_view/mydesign/myview
>>>> B) GET /db/_show_view/mydesign/myshowfunc/myview
>>>> C) GET /db/_view/mydesign/myview?strartkey="foo"&show=myshowfunc
>>>
>>> Call me thick but C looks cleaner to me.
>>>
>>>> {
>>>> ...
>>>> "show" : {
>>>> "docs" : { ... },
>>>> "views" : {
>>>> "myshowfunc" : "function(row, head) { ... }"
>>>> }
>>>> }
>>>
>>> how about including your show fns in show { } ?
>>
>> that's what's above
>>
>> show funcs for documents are at
>>
>> ddoc.show.docs
>>
>> and show funcs for views are at
>>
>> ddoc.show.views
>>
>>
>> I'm leaning B or C as well.
>>
>> My main reservation about C is what it will do to the internals.
>> Erlang actions that are scoped to a _private_path URL can be kept in
>> their own module and moved around via the config API. If we amke it
>> an
>> options on regular views, we lose that freedom.
>>
>> Also, I do like the current URL scheme for document show funcs,
>> partly
>> for the config reason, but also because I think
>>
>> GET /db/_show/mydesign/myshowfunc/docid
>>
>> is clearer than
>>
>> GET /db/docid?show=mydesign/myshowfun
>>
>>>
>>> {
>>> ...
>>> views: {
>>> foo : { map : ... }
>>> },
>>> show: {
>>> as_xml: function(...) { ... },
>>> }
>>> }
>>>
>>>> I'm leaning toward letting the user decide at query-time which
>>>> view to
>>>> render using which show-func, that is, options B or C.
>>>
>>> Well I thought that that was a given, flexibility so that users can
>>> define a couple of views, a couple of shows so that the combinations
>>> then are more useful.
>>>
>>> U
>>>
>>
>>
>>
>> --
>> Chris Anderson
>> http://jchris.mfdz.com
>>
>
>
>
> --
> Chris Anderson
> http://jchris.mfdz.com
Re: _show API (née _form)
Posted by Chris Anderson <jc...@gmail.com>.
Is there a better url path than _show_view? Let's imagine a query
(with descriptive names):
Viewing the "sofa/resent-posts" view with show the function "as-html",
this is option (B)
B) GET /db/_show_view/sofa/as-html/recent-posts
Maybe this would look better like:
D) GET /db/_look/sofa/recent-posts/as-html
except _look is kinda silly. I do think having readable urls, is a
good way to relax.
(D) translates as
D) GET /db/_look/designname/myview/myshow
On Mon, Jan 12, 2009 at 12:12 PM, Chris Anderson <jc...@gmail.com> wrote:
> On Mon, Jan 12, 2009 at 11:57 AM, Ulises <ul...@gmail.com> wrote:
>>> A) GET /db/_show_view/mydesign/myview
>>> B) GET /db/_show_view/mydesign/myshowfunc/myview
>>> C) GET /db/_view/mydesign/myview?strartkey="foo"&show=myshowfunc
>>
>> Call me thick but C looks cleaner to me.
>>
>>> {
>>> ...
>>> "show" : {
>>> "docs" : { ... },
>>> "views" : {
>>> "myshowfunc" : "function(row, head) { ... }"
>>> }
>>> }
>>
>> how about including your show fns in show { } ?
>
> that's what's above
>
> show funcs for documents are at
>
> ddoc.show.docs
>
> and show funcs for views are at
>
> ddoc.show.views
>
>
> I'm leaning B or C as well.
>
> My main reservation about C is what it will do to the internals.
> Erlang actions that are scoped to a _private_path URL can be kept in
> their own module and moved around via the config API. If we amke it an
> options on regular views, we lose that freedom.
>
> Also, I do like the current URL scheme for document show funcs, partly
> for the config reason, but also because I think
>
> GET /db/_show/mydesign/myshowfunc/docid
>
> is clearer than
>
> GET /db/docid?show=mydesign/myshowfun
>
>>
>> {
>> ...
>> views: {
>> foo : { map : ... }
>> },
>> show: {
>> as_xml: function(...) { ... },
>> }
>> }
>>
>>> I'm leaning toward letting the user decide at query-time which view to
>>> render using which show-func, that is, options B or C.
>>
>> Well I thought that that was a given, flexibility so that users can
>> define a couple of views, a couple of shows so that the combinations
>> then are more useful.
>>
>> U
>>
>
>
>
> --
> Chris Anderson
> http://jchris.mfdz.com
>
--
Chris Anderson
http://jchris.mfdz.com
Re: _show API (née _form)
Posted by Chris Anderson <jc...@gmail.com>.
On Mon, Jan 12, 2009 at 11:57 AM, Ulises <ul...@gmail.com> wrote:
>> A) GET /db/_show_view/mydesign/myview
>> B) GET /db/_show_view/mydesign/myshowfunc/myview
>> C) GET /db/_view/mydesign/myview?strartkey="foo"&show=myshowfunc
>
> Call me thick but C looks cleaner to me.
>
>> {
>> ...
>> "show" : {
>> "docs" : { ... },
>> "views" : {
>> "myshowfunc" : "function(row, head) { ... }"
>> }
>> }
>
> how about including your show fns in show { } ?
that's what's above
show funcs for documents are at
ddoc.show.docs
and show funcs for views are at
ddoc.show.views
I'm leaning B or C as well.
My main reservation about C is what it will do to the internals.
Erlang actions that are scoped to a _private_path URL can be kept in
their own module and moved around via the config API. If we amke it an
options on regular views, we lose that freedom.
Also, I do like the current URL scheme for document show funcs, partly
for the config reason, but also because I think
GET /db/_show/mydesign/myshowfunc/docid
is clearer than
GET /db/docid?show=mydesign/myshowfun
>
> {
> ...
> views: {
> foo : { map : ... }
> },
> show: {
> as_xml: function(...) { ... },
> }
> }
>
>> I'm leaning toward letting the user decide at query-time which view to
>> render using which show-func, that is, options B or C.
>
> Well I thought that that was a given, flexibility so that users can
> define a couple of views, a couple of shows so that the combinations
> then are more useful.
>
> U
>
--
Chris Anderson
http://jchris.mfdz.com
Re: _show API (née _form)
Posted by Ulises <ul...@gmail.com>.
> A) GET /db/_show_view/mydesign/myview
> B) GET /db/_show_view/mydesign/myshowfunc/myview
> C) GET /db/_view/mydesign/myview?strartkey="foo"&show=myshowfunc
Call me thick but C looks cleaner to me.
> {
> ...
> "show" : {
> "docs" : { ... },
> "views" : {
> "myshowfunc" : "function(row, head) { ... }"
> }
> }
how about including your show fns in show { } ?
{
...
views: {
foo : { map : ... }
},
show: {
as_xml: function(...) { ... },
}
}
> I'm leaning toward letting the user decide at query-time which view to
> render using which show-func, that is, options B or C.
Well I thought that that was a given, flexibility so that users can
define a couple of views, a couple of shows so that the combinations
then are more useful.
U
Re: _show API (née _form)
Posted by Chris Anderson <jc...@gmail.com>.
On Mon, Jan 12, 2009 at 11:09 AM, Paul Davis
<pa...@gmail.com> wrote:
> On Mon, Jan 12, 2009 at 2:01 PM, Chris Anderson <jc...@gmail.com> wrote:
>> On Mon, Jan 12, 2009 at 12:21 AM, Ulises <ul...@gmail.com> wrote:
>>>> I see where you're coming from, but I don't like this very much. My
>>>> thoughts were something along the lines of being able to have multiple
>>>> show functions per view. We could do the repeating the view code but
>>>> that's really not good.
>>>
>>> FWIW, +1 on multiple shows per view. Following the MVC ideology, we
>>> could say that the couchdb view is actually the model (the data) and
>>> that the couchdb _show is the MVC view (the presentation). It only
>>> makes sense (at least to me) to be able to present the same data in
>>> many different ways, i.e. XML or JSON.
>>>
>>
>> There's no limit on the ways you can present it, even with a single
>> function. You can always switch on the clients Accept header, or on
>> query parameters. This is really a question about how to organize the
>> urls and the design docs. I do like your point about MVC.
>>
>> The nice thing about one function per view is that it allows for
>> shorter paths, the downside is potentially more complex functions. I
>> *think* it's straightforward that we should only allow views to be
>> rendered by show functions defined in the same design doc as the view,
>> but I could be convinced of the merits otherwise.
>
> Using show's to process views from other design docs sounds like more
> code for the same level of usefulness. Also I think that it might
> convey the wrong idea in terms of how to design applications etc. But
> I could still be convinced otherwise.
>
OK lets assume that we don't want to do that (I think it's a bad idea too)
So for view showing we'd have something like:
A) GET /db/_show_view/mydesign/myview
or
B) GET /db/_show_view/mydesign/myshowfunc/myview
or
C) GET /db/_view/mydesign/myview?strartkey="foo"&show=myshowfunc
and in the design doc:
{
...
"show" : {
"docs" : { ... },
"views" : {
"myshowfunc" : "function(row, head) { ... }"
}
}
In the case with one show function per view, we'd require that
"myshowfunc" have the same name as "myview"...
I'm leaning toward letting the user decide at query-time which view to
render using which show-func, that is, options B or C.
--
Chris Anderson
http://jchris.mfdz.com
Re: _show API (née _form)
Posted by Paul Davis <pa...@gmail.com>.
On Mon, Jan 12, 2009 at 2:01 PM, Chris Anderson <jc...@gmail.com> wrote:
> On Mon, Jan 12, 2009 at 12:21 AM, Ulises <ul...@gmail.com> wrote:
>>> I see where you're coming from, but I don't like this very much. My
>>> thoughts were something along the lines of being able to have multiple
>>> show functions per view. We could do the repeating the view code but
>>> that's really not good.
>>
>> FWIW, +1 on multiple shows per view. Following the MVC ideology, we
>> could say that the couchdb view is actually the model (the data) and
>> that the couchdb _show is the MVC view (the presentation). It only
>> makes sense (at least to me) to be able to present the same data in
>> many different ways, i.e. XML or JSON.
>>
>
> There's no limit on the ways you can present it, even with a single
> function. You can always switch on the clients Accept header, or on
> query parameters. This is really a question about how to organize the
> urls and the design docs. I do like your point about MVC.
>
> The nice thing about one function per view is that it allows for
> shorter paths, the downside is potentially more complex functions. I
> *think* it's straightforward that we should only allow views to be
> rendered by show functions defined in the same design doc as the view,
> but I could be convinced of the merits otherwise.
Using show's to process views from other design docs sounds like more
code for the same level of usefulness. Also I think that it might
convey the wrong idea in terms of how to design applications etc. But
I could still be convinced otherwise.
Paul Davis
> Again, the trade-off
> would be longer paths for "more flexibility".
>
> --
> Chris Anderson
> http://jchris.mfdz.com
>
Re: _show API (née _form)
Posted by Chris Anderson <jc...@gmail.com>.
On Mon, Jan 12, 2009 at 12:21 AM, Ulises <ul...@gmail.com> wrote:
>> I see where you're coming from, but I don't like this very much. My
>> thoughts were something along the lines of being able to have multiple
>> show functions per view. We could do the repeating the view code but
>> that's really not good.
>
> FWIW, +1 on multiple shows per view. Following the MVC ideology, we
> could say that the couchdb view is actually the model (the data) and
> that the couchdb _show is the MVC view (the presentation). It only
> makes sense (at least to me) to be able to present the same data in
> many different ways, i.e. XML or JSON.
>
There's no limit on the ways you can present it, even with a single
function. You can always switch on the clients Accept header, or on
query parameters. This is really a question about how to organize the
urls and the design docs. I do like your point about MVC.
The nice thing about one function per view is that it allows for
shorter paths, the downside is potentially more complex functions. I
*think* it's straightforward that we should only allow views to be
rendered by show functions defined in the same design doc as the view,
but I could be convinced of the merits otherwise. Again, the trade-off
would be longer paths for "more flexibility".
--
Chris Anderson
http://jchris.mfdz.com
Re: _show API (née _form)
Posted by Ulises <ul...@gmail.com>.
> I see where you're coming from, but I don't like this very much. My
> thoughts were something along the lines of being able to have multiple
> show functions per view. We could do the repeating the view code but
> that's really not good.
FWIW, +1 on multiple shows per view. Following the MVC ideology, we
could say that the couchdb view is actually the model (the data) and
that the couchdb _show is the MVC view (the presentation). It only
makes sense (at least to me) to be able to present the same data in
many different ways, i.e. XML or JSON.
U
Re: _show API (née _form)
Posted by Paul Davis <pa...@gmail.com>.
On Fri, Jan 9, 2009 at 1:12 PM, Chris Anderson <jc...@gmail.com> wrote:
> On Fri, Jan 9, 2009 at 2:01 PM, Dean Landolt <de...@deanlandolt.com> wrote:
>> At the very least there should be a symmetry between the doc _show api and
>> the view _show api, and
>
> Hows this for asymmetry? :)
>
> I did not mention one alternative URL address option. Just using the
> standard view urls as they are, but adding show=true, like:
>
> GET /db/_view/mydesign/myview?startkey="b"&limit=10&show=true
>
I see where you're coming from, but I don't like this very much. My
thoughts were something along the lines of being able to have multiple
show functions per view. We could do the repeating the view code but
that's really not good.
>> while switching on passed in parameters is
>> technically all the same, the internals of _show_view functions sound like
>> they'll be complex enough with head/tail/row semantics.
>>
>
> There's another question altogether, about how to structure the design document.
>
I was kinda assuming it'd be something like:
{
"_id": "_design/foo",
"views": {
"bar": {
"map": "function(doc) {emit(doc._id, null);}"
}
},
"show": {
"docs": {
"xml": "function ... return doc as xml",
"doc_foo": "function ... return part of doc like ML guy wanted"
"views": {
"atom": {
"source": "bar",
"head": "function ... return head of atom stream",
"rows": "function .... etc",
"tail": "function .... miracle"
}
}
}
}
> --
> Chris Anderson
> http://jchris.mfdz.com
>
Re: _show API (née _form)
Posted by Chris Anderson <jc...@gmail.com>.
On Fri, Jan 9, 2009 at 2:01 PM, Dean Landolt <de...@deanlandolt.com> wrote:
> At the very least there should be a symmetry between the doc _show api and
> the view _show api, and
Hows this for asymmetry? :)
I did not mention one alternative URL address option. Just using the
standard view urls as they are, but adding show=true, like:
GET /db/_view/mydesign/myview?startkey="b"&limit=10&show=true
> while switching on passed in parameters is
> technically all the same, the internals of _show_view functions sound like
> they'll be complex enough with head/tail/row semantics.
>
There's another question altogether, about how to structure the design document.
--
Chris Anderson
http://jchris.mfdz.com
Re: _show API (née _form)
Posted by Dean Landolt <de...@deanlandolt.com>.
On Fri, Jan 9, 2009 at 4:51 PM, Paul Davis <pa...@gmail.com>wrote:
> Renaming to _show: +1
> Keeping multiple functions: +1
>
> Multiple functions would allow me to do things like:
>
> http://127.0.0.1:5984/db_name/_show/foo/xml/docid right?
>
> It seems like multiple functions would reduce complexity in the show
> function implementations. Also, isn't this just the same as making
> design documents have a single view? I think that'd be fairly silly.
>
> Also, it kinda violates the "one design doc is an application" idea.
> And by violates, I means, chops the balls of the feature for anyone
> trying to stick to it. :D
Brilliantly poetic ;)
At the very least there should be a symmetry between the doc _show api and
the view _show api, and while switching on passed in parameters is
technically all the same, the internals of _show_view functions sound like
they'll be complex enough with head/tail/row semantics.
Re: _show API (née _form)
Posted by Paul Davis <pa...@gmail.com>.
Renaming to _show: +1
Keeping multiple functions: +1
Multiple functions would allow me to do things like:
http://127.0.0.1:5984/db_name/_show/foo/xml/docid right?
It seems like multiple functions would reduce complexity in the show
function implementations. Also, isn't this just the same as making
design documents have a single view? I think that'd be fairly silly.
Also, it kinda violates the "one design doc is an application" idea.
And by violates, I means, chops the balls of the feature for anyone
trying to stick to it. :D
HTH,
Paul Davis
On Fri, Jan 9, 2009 at 11:39 AM, Chris Anderson <jc...@apache.org> wrote:
> This is a summary of an IRC discussion prompted by Christopher Lenz
> about the "forms" name and API.
>
> The recently introduced _form feature is still rough. On IRC today we
> managed to come up with a better name: _show. We like _show because it
> makes clear that these functions are for formatting, and that they are
> side-effect free, without overloading html's use of the word "form".
>
> The API changes I'm describing haven't been implemented yet, but could
> happen soon. The question about the _view show API is a bit more open,
> as we don't have an implementation yet. The doc _show API has a subtle
> question about whether to use path segments or query params for
> function switching.
>
>
> == The view _show API
>
> The paradigm use case for view forms is generating Atom feeds from
> views. By doing this in a CouchDB show function, you'll get row at a
> time streaming and low memory overhead, while being able to service
> even giant key ranges.
>
> The first question is about user needs. It would be cleaner and easier
> to develop a view-show API where each view has only one show function.
> Within a function you can still switch on Accept-header (or query
> string) so the same function can do both say Atom and RSS feeds.
>
> Is there a strong reason to have more than one show function per view?
> I think having more could lead to developer confusion (the inside of a
> view show function will be a bit more complex than rereduce even --
> head, tail, and row modes), and you can always switch on the query
> string...
>
> Assuming the one-form-pre-view constraint, here are some options for
> the URL structure:
>
> GET /db/_show_view/mydesign/myview
>
> This would handle the same set of query parameters as the view api, so
> you could use startkey, limit, skip etc.
>
> GET /db/_show_view/mydesign/myview?startkey=["foo", "bar"]
>
> Also the full set of query parameters would be available to the show
> function so that devs could add eg ?nickname="J Chris A" if they
> wanted to render a nickname into the view at runtime (and wreck
> cacheability).
>
>
> == Subtleties in the doc _show API
>
> To run a document through a show function, the URL is:
>
> GET /mydb/_show/mydesign/myshowfunc/docid
> GET /mydb/_show/mydesign/othershowfunc/docid
>
> Currently each design doc can have a set of show functions.
>
> If we were to restrict the design doc to a single show function, we'd
> have slightly shorter urls:
>
> GET /mydb/_show/mydesign/docid
>
> Should devs need to multiplex on user request, they could use query
> string parameters (which are also available in the current
> implementation) eg:
>
> GET /mydb/_show/mydesign/docid?specifically=editdoc
>
> so technically the two options have the same capabilities.
>
> I find the current implementation a little easier to think about (it
> results in smaller _show functions), and I think the URL length is not
> a problem, really. Or rather that the additional length will usually
> turn out to be descriptive of its purpose, so it's a net win.
>
>
> --
> Chris Anderson
> http://jchris.mfdz.com
>