Hi
I agree quite a bit about the coucapp. Hence couldnt help but comment.
Couchapp does seem to have quite a few rough corners feel to it - when
compared to the soundness of couchdb as a whole (even without bigcouch
etc).
I have been using a self written tool to push view/list/show code to
couchdb from using a makefile for my project. A sample line from the
makefile is as follows:
belongs_view:
update_field.py -u $(COUCH) $(DBNAME) _design/ids views.belongs.map
belongs.js
This pushes belongs.js to key db["_design/ids"].views.belongs.map ,
recursively creating any intermediate json objects as needed.
It has worked well for me because I get to edit my javascript code in
any editor. And unlike couchapp, I do not need to install a python
package (particularly one which does not seem to have heavy community
support).
The use case for couchapp is mentioned as sharing code between views (
http://wiki.apache.org/couchdb/HTTP_view_API#Sharing_Code_Between_Views
). At the cost of adding shared code into common js modules
explicitly, I get the convenience of "what you see is what you get" -
unlike the inclusion of code through JS comments in couchapp.
If the overall idea of having a standalone tool is attractive, I can
surely improve it a bit (eg: usage line can improve, etc) and share
more widely. It anyway was created under an apache 2 licence.
Thanks
Vivek
On 11/30/13, 10:33 PM, Alexander Shorin wrote:
On Sun, Dec 1, 2013 at 4:20 AM, Russell Branca <[email protected]> wrote:
In its current form, couchapp.org is a relic that has been mostly abandoned
and is not maintainable by the community. I strongly feel we should move
the couchapp documentation into official documentation. I see two relevant
points of interest in this discussion. First is the notion of couchapps as
the self contained application platform that utilizes show/list functions,
and whether these should be included in CouchDB. I don't think this is the
important issue at hand.
The bigger issue is that the defacto method of defining design documents is
to use one of the many "couchapp" tools, and the only place this is
documented as a whole is couchapp.org. This is a disservice to the
community, and one that needs to be resolved. This is a constant source of
confusion to new users who quickly realize the futility of defining design
docs in the browser, and get lost when told "just use a couchapp", and then
they inevitably end up clicking on the top google result for "couchapp",
couchapp.org. We need to have this properly documented in the official
documentation so that the process is fully defined for new users.
A couple of options for approach would be to formalize the folder
definition of a couchapp and list tools known to be compatible, or to
officially bless a tool like Erica. While I do want to see Fauxton provide
powerful editors for all the different function types, I don't think this
is sufficient as people typically want to keep their design docs raw code
under SCM. Whatever approach is taken, I think the number one priority here
is ensuring proper documentation explaining to users best practices for
defining and maintaining design docs.
-Russell
+1 and actually I'm only waiting for rcouch merge and having erica as
builtin tool. There is already big place to land all the stuff in
source code tree and even named also as "couchapp" since it provides
huge potential for more interesting and rich content rather than just
"ddoc" or similar.
--
,,,^..^,,,
