You're right, cocoon.load() already supports this. I'll test it when I get home. Do you think "load" should be a method of the "cocoon" object?
-----Original Message----- From: Pier Fumagalli [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 3:38 PM To: [EMAIL PROTECTED] Subject: Re: Stabilizing flow in order to release 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
