On Jan 18, 10:51 am, Attila Szegedi <szege...@gmail.com> wrote:
> Yes, absolutely - I would create an interface:
>
> public interface ModuleScriptProvider
> {
> public Script getModuleScript(Context cx, String scriptId);
>
> }
>
> and the embedding code would be responsible for providing an implementation
> of it.
>
> Attila.
>
> On 2010.01.18., at 17:49, Martin Blom wrote:
>
>
>
> > On 01/17/10 07:35 PM, Attila Szegedi wrote:
> >> Folks,
>
> >> I'm contemplating adding CommonJS Modules implementation to Rhino codebase
> >> proper. I'd create org.mozilla.javascript.commonjs package to hold it, and
> >> we could have a method similar to initStandardObjects(), i.e.
> >> initCommonJs() that'd initialize it - basically install a require()
> >> function with the expected semantics in the top-level scope. I want leave
> >> some of its aspects - most notably lookup of the module script -
> >> pluggable, defined by interfaces in the org.mozilla.javascript.commonjs
> >> package, so that specific embeddings of Rhino (JS app servers) can install
> >> their own module resolver logic. I'd provide a default implementation for
> >> the shell too.
>
> >> As I foresee that several Rhino-based JS products will adopt CommonJS in
> >> the near future, it seems desirable to not have all of them reinvent the
> >> wheel (even though some already did, I'm guilty of coding my own require()
> >> too in the next-gen version of my company's server-side JS enviroment...).
>
> >> Opinions?
>
> > As long as the code embedding Rhino is responsible for resolving the module
> > files (using it's own search paths, for instance): Sounds great!
>
> > --
> > ---- Martin Blom --------------------------- mar...@blom.org ----
> > Eccl 1:18 http://martin.blom.org/
This sounds great!
_______________________________________________
dev-tech-js-engine-rhino mailing list
dev-tech-js-engine-rhino@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
