On Mon, Aug 27, 2012 at 10:14 PM, Sam Tobin-Hochstadt <[email protected]> wrote:
>> So in /lib/b.js , System.baseURL will return a diff result
>> "http://example.com/lib/b.js"; ?
>
> This depends on how you're loading "b.js".
>
Could explain more about that? I suppose b.js is loaded by system loader.
>>
>> I want:
>>
>> /a/*.js
>> myLoader.load('test.js') // load /a/test.js
>>
>> /b/*.js
>> myLoader.load('test.js') // load /b/test.js
>>
>> But myFetch get the identical args: ('test.js', myLoader.baseURL)
>>
>> HOW can myFetch know the correct URL? (Holding System.baseURL seems
>> useless in this case.)
>
> `load` is a method, which can be called anywhere. Having it depend on
> a dynamically-scoped bit of information such as the url of the file
> that the method is called in, would make using loaders much harder to
> understand.
I don't think so. Loader is a very special util, and I believe most
coders expect the behavior I described, and that also match the
behavior of System loader (what I confirmed in early post), or require
in CommonJS.
>
> This is just like current browser behavior when you insert a `<script
> src="test.js">` tag -- "test.js" is looked up relative to the URL of
> the *page*, not relative to the URL of the js file that does the dom
> manipulation.
That's WHY we need loader in JS, not script tag in HTML.
And current ES3/5 loaders are all trying to solve the base URL by
tricks (such as check script.readystate and find which script is
running and get the right baseURL)
--
hax
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
