For the record, I think it's important to remember that design docs
are extensible, i.e. couchapp-style tools should also support
'fulltext' (couchdb-lucene), 'spatial' (geocouch), etc members. In
general, that means blindly building a design doc from whatever bits
(js, json, plain text) are on disk. I think both couchapp and erica
handle this already.
I really see couchapp-style tools in a two parts:
1. Project starter. Dumps a typical directory structure to disk
according to some template, e.g. erica's create-app and create-webapp
or couchapp's startapp and generate commands.
2. Pull/clone. Updates a database from whatever is on disk or vice versa.
Would it make sense to provide two distinct tools? The pull/clone tool
might even be the only tool that's included in apache's couchdb
distribution, which is likely to appeal to those who see couchdb as
purely a database and should be easy to get in very quickly.
- Matt
On 4 December 2013 22:11, Benjamin Young <byoung@bigbluehat.com> wrote:
> On 11/30/13, 7:20 PM, Russell Branca wrote:
>>
>> A couple of options for approach would be to formalize the folder
>> definition of a couchapp and list tools known to be compatible
>
>
> First parts done:
> https://github.com/couchapp/couchapp/wiki/Complete-Filesystem-to-Design-Doc-Mapping-Example
>
> erica and couchapp(.py) both support it.
>
> node.couchapp.js can also support the format if the app.js is setup properly
> via couchapp.loadFiles() for each key.
>
> kan.so can as well:
> http://kan.so/docs/Kanso_for_developers_using_the_python_couchapp_tool
|