couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikeal Rogers <mikeal.rog...@gmail.com>
Subject Re: CommonJS in map and reduce
Date Mon, 20 Sep 2010 15:44:48 GMT
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 <stephenp@agrussell.com>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
>>
>>
>

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