cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <p...@betaversion.org>
Subject Re: Stabilizing flow in order to release
Date Tue, 04 Mar 2003 23:38:19 GMT
On 4/3/03 22:08, "Christopher Oliver" <res1cf5x@verizon.net> 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




Mime
View raw message