On 4/3/03 22:08, "Christopher Oliver" <[EMAIL PROTECTED]> wrote:
> Jakob Praher wrote:
>> Am Die, 2003-03-04 um 18.52 schrieb Christopher Oliver:
>>
>>
>>> Not sure. This is one of the weaknesses of JavaScript. It doesn't have
>>> any structuring mechanism for creating libraries or reusable modules
>>> (which was one of the things JavaScript 2.0 was supposed to fix). I
>>> think Cocoon will have to invent its own mechanisms to describe and
>>> manage script libraries.
>>
>> I could also imagine using SourceResolvers like in the sitemap here.
>>
>> Like
>>
>> include( 'js:/x/y/z.js' )
>> or
>> import( 'js:/x/y/z.js' )
>>
>> whereas import does not override existing declarations and include is
>> just a cut'n paste of it.
>>
>> include and import woud simply be FunctionObjects that get bootstrapped
>> at initialization time.
>>
>> they take a String as a parameter and hand this to a SourceResolver,
>> which in turn knows how and where to load it from.
>>
>> just my 2 cents.
>
> That sounds like a good idea to me. There wouldn't be a "js:" protocol
> though, would there? I mean, I can just do this:
>
> include("file:/x/y/z.js");
> include("resource://q/x.js");
>
> etc.
>
> I've now implemented this in my development environment as "include". We
> can't use "import" as the name - that's a javascript keyword.
>
> For what it's worth the standard Rhino shell calls this function "load()".
>
> I can check it in if necessary.
>
> What do others think?
That "cocoon.load("...") should actually do the trick already... If it
doesn't support SourceResolver(s), that is the place we oughta fix things.
Pier
