On 25.02.2009, at 06:16, Chris Anderson wrote:
[snip]
Currently, there is no way for an html attachment to a design document
to link to other resources provided by that design document, absent
client side scripting, or hardcoding the design document name in the
html (neither of which are acceptable).
If you are the HTML hosted at /db/_design/foo/index.html and you want
to provide browsers a link to /db/_view/foo/bar?limit=10 you can't.
You can link to other attachments in the same design document, very
easily.
One way to fix this it to give the resources made available by a
design document a common root. This means we can use hrefs like
"_show/docid" to link to a show function from an attachment. So we
get paths like this:
/db/_design/foo/_view/bar?limit=10
/db/_design/foo/_show/docid
/db/_design/foo/index.html
The downside is that the URLs are longer (and that the change would
break all clients), the upside is the ability to link from one to the
other (and thus be part of the web).
I'm in favor of this change. It would be nice if couchapp-style
applications were able to use relative URLs, and don't have to care
about the name of the design doc they've been placed in. Sure breaks
backwards compatibility badly, but I think it's worth it in this case.
== A related question ==
I checked a patch into Futon the other day (with a note here on dev@)
that links to any apps that are in any of your databases. This is not
meant as an end-user API. It is a step toward an end-user API. The key
similarity is the process for discovering apps. In my mind, an app is
a design document that provides a user interface.
Here's the screenshot of that feature that I linked from my earlier
dev post: http://img.skitch.com/20090225-
ttb3gmd86unthjw9i6cqhjs9c9.png
Each app has a start page. Currently, an app's start page is defined
in the design_doc.couchapp.index field. (The details of that field are
subject to change based on the previous section of this mail.) If the
couchapp.index field does not exist, but the design doc has an
index.html attachment, then that is used as its start page. If a
design doc has neither the field nor an index.html attachment, it is
not considered to be an app, and is not linked to from Futon.
The question raised by all of this is how closely do we want CouchDB
to be intertwined with CouchApp?
I think that, at least for the time being, it's best if CouchApp
remained a separate project, in the sense that nothing in CouchDB
should know about the CouchApp side. I certainly agree that CouchApp-
style applications are pretty exciting (albeit in a very alpha-geekish
way), but I also think there will continue to be a large percentage of
CouchDB users (myself included) who use CouchDB in a more traditional
way, as a storage backend sitting behind a regular web-based
application, with a web server sitting between the user and the
database. In my opinion we should go out of our way to avoid the
impression that CouchApps are the preferred/endorsed way to use CouchDB.
In that vein, I'm not in favor of the CouchApp links on the Futon
start page. I've generally tried to keep Futon extremely neutral to
the specific ways people may use CouchDB, and the CouchApp links smell
too much like an official endorsement of one particular method to me.
Plus, the "Applications" column must be rather confusing for any
CouchDB users who haven't played with the CouchApp concept yet ("Hum,
how do I get my PHP scripts in there?" [not that anyone should be
writing PHP scripts in the first place]).
Ideally, we'd have some way in Futon for extensions to register their
own pages that show up in the sidebar navigation (that might be as
simple as a config section, if we didn't have that pesky admin auth
prompt for reading config values ;) ). If we had that, I think there
should be a CouchApp plugin that registered an "Applications" page
that could do some discovery on demand. Actually, I'd go even further,
and suggest that the "show" and "list" features should be part of that
CouchApp plugin, and not actually included with CouchDB itself. You
really only need those features when you're developing CouchApp-style
applications. Moving them into a corresponding plugin would help keep
CouchDB itself lean and clean.
Moving those into a plugin should be almost trivial on the Erlang
level AFAICT. The problem is the Javascript "query server", which by
now is full of stuff I personally don't use… some of them just for
tests, some for "external", some for "show"/"list". I think we'll need
to figure out a good way to split up good ole main.js (and maybe even
couchjs) so that CouchDB only includes the commonly used parts, but
extensions can add whatever they may need. The current approach of one
"query_server" (which has long been misnomer) per language
implementing all the hooks is going to break down pretty fast. Maybe,
we should have [view_servers], [validation_servers], [render_servers],
and so on, instead. Only with proper names.
And for the record, I still think "show" and "list" are not good names
for what they do :) But then again, if they'd get moved out into an
external CouchApp plugin, I wouldn't have to care (as long as I don't
become a CouchApp aficionado, that is).
Cheers,
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
