Great writeup.
The only thing I think it's lacking is how the require namespaces will
differ.
So, refresher, require('foo') means import a module that is a top level
attribute in the design doc named "foo". Basically the commonjs module
namespace is scoped to the ddoc root. This will stay the same for require
outside of map/reduce.
In map/reduce all we'll do is re-scope the root namespace for require to the
ddoc "views" attribute.
All the "relative" imports, like require('./module'), will work the same but
we'll probably have some safe guard from doing '../../../' to get out of the
views sandbox.
-Mikeal
On Mon, Sep 20, 2010 at 4:55 PM, Chris Anderson <jch...@apache.org> 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
>
