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 --------------------------- [email protected] ----
> Eccl 1:18 http://martin.blom.org/
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
