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?
