incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lance Carlson <>
Subject Re: show/list
Date Thu, 14 Nov 2013 20:32:23 GMT
I really like the idea of shows/list, and would love them even more if:

- The js interpretor was NodeJS
- There was better documentation on their use and using CommonJS and maybe
NPM modules in your couchapps.

I'm not sure why people immediately revert to the old ways of wanting to
stick a layer in front of their infrastructure to handle view generation. I
understand that the existing framework tool chains have already figure this
stuff out (Although I argue that if shows/lists were embraced with even
fuller "color" the design could become even cleaner than traditional MVC
frameworks). I am a huge proponent of modularization and SRP, so I wouldn't
mind if these features were a standalone module, but I would include them
in the bundle and make you uninstall them. It's a feature that is very
unique to couchdb and fills the very tagline advertised on the website "A
database for the web". The web is HTML. Let's embrace that fact and make
shows/lists as powerful as they can be. Let's hype them up and recode the
coolest blog/forum/HNclones using that platform and have conferences and
tell show everyone how cool we are for using the latest technology. THIS is
how innovation happens.

On Thu, Nov 14, 2013 at 3:06 PM, Filippo Fadda <> wrote:

> On Nov 14, 2013, at 8:08 PM, Alexander Shorin wrote:
> > On Thu, Nov 14, 2013 at 9:58 PM, Filippo Fadda
> > - Provide different from JSON response to clients: browsers,
> > non-couchdb clients (mostly xml driven), etc.
> You can do them in PHP or Ruby. In Rails you need 2 lines of code.
> I'm not gonna to expose my database just to serve some different client,
> all the urls are handled by a web server and I will serve any client from
> the web server. Security, consistence, scalability.
> > - Transform response without sharing same logic with every client.
> You are missing something here. In a modern application all clients are
> handled by the same web application. The application provide the right
> answer in function of the caller. Browser will receive HTML, rss consumers
> will receive XML, third part applications will receive JSON from APIs.
> > Oh, get ready to be smashed by Javascript guys - there are a lot of
> > tools to make rich JS couchapps (:
> I know, but as Joan wrote in his presentation, if you are using a
> framework (Rails, Django, Phalcon, Zend Framework, Symfony, Sinatra,
> Bottle, Lavarel and many others), those handlers are useless, at least for
> the purpose described in the documentation. You don't need them, you are
> just gonna complicate your life.
> They still stands to be used in CouchApps, but you don't develop CouchApps
> with ElephantOnCouch. :-)
> A nice feature I have in ElephantOnCouch, for example, is the
> Stanley made a point using them for specific tasks, but the problems he
> solved using show and list could be solved in many other ways, and their
> use, at least for me, in the cases he has spoken about, is a bit tricky.
> Anyway this is just my opinion. :-)
> -Filippo

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message