cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <res1c...@verizon.net>
Subject Re: Stabilizing flow in order to release
Date Tue, 04 Mar 2003 22:08:04 GMT
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?


Mime
View raw message