CommonJS modules are javascript specific. The only *special* thing we would be doing is saying that an attribute on views that doesn't have a "map" attribute won't be considered a valid map function but will be used in the hash. That's easily portable to other languages if you are embedding the modules in the design document.
-Mikeal On Mon, Sep 20, 2010 at 5:16 PM, Stephen Prater <[email protected]>wrote: > Would this implementation be view server agnostic? > > How would it work with (say, theoretically) the Ruby view server? > > Although it's much harder to enforce the "don't import" rule in languages > other than javascript, it would be nice to provide a "blessed" way to do a > require for your view. > > > On Sep 20, 2010, at 9:55 AM, Chris Anderson wrote: > > Devs, >> >> Mikeal and I were talking and we came up with a sane way to do >> CommonJS in map and reduce. >> >> Refresher: we don't have CommonJS require there now because the >> current CommonJS implementation is scoped to the whole design doc, and >> giving views access to load code from anywhere in the design doc would >> mean we'd have to blow away your view index anytime you changed >> anything. Having to rebuild views from scratch just because you >> changed some CSS or a show function isn't fun,so we avoided the issue >> by keeping CommonJS require out of map and reduce altogether. >> >> The solution we came up with is to allow CommonJS inside map and >> reduce funs, but only of libraries that are stored inside the views >> part of the design doc. >> >> So you could continue to access CommonJS code in design_doc.foo, from >> your list functions etc, but we'd add the ability to require CommonJS >> modules within map and reduce, but only from design_doc.views.lib >> >> There's no worry here about namespace collisions, as Couch just plucks >> views.*.map and views.*.reduce out of the design doc. So you could >> have a view called "lib" if you wanted, and still have CommonJS stored >> in views.lib.sha1 and views.lib.stemmer if you wanted. >> >> We could allow CommonJS modules to be stored anywhere in ddoc.views, >> but I think it will simplify the implementation to enforce that they >> be stored in views.lib -- if people think that is too restrictive, >> please speak up now, otherwise I'll start to implement this. >> >> Chris >> >> >> -- >> Chris Anderson >> http://jchrisa.net >> http://couch.io >> >> >
