This way you only get the bits necessary per page, this doesn’t make sense for something as small as Prototype but as I was building the JS Library for eProject it made sense to include this feature since we have so many packages available.
I’ve just recently been running into a problem implementing a Dojo style dynamic package inclusion system in our companies new JS Library. I didn’t want to dig into the Dojo source code to much, so I implemented a rather crude solution of taking the string to require, converting it to a file system path and appending a script element with that path to the page.
dojo.io.* would become dojo/io.js
This was a really simple solution and worked great in FireFox, but in IE (eProject is only concerned with these two browsers at the moment) , there were loading issues. It appears that unless the file is cached, it took its own sweet ass time loading. Annoyingly this made it seem that all my unit tests were passing when in fact, they only were passing because the dynamically included packages were already cached in most cases.
So after some digging into the dojo source a bit, I’ve discovered how they avoid this irritating little “feature”. The dojo toolkit uses an XML HTTP GET (for cache support of course) call to retrieve the contents of the file from the server, and eval()’s the returnText.
Ever since I read this, I’ve been trying to avoid it, it means I have to write custom XML HTTP Logic in the base framework level, and I have to do eval()’s on large blocks of text, but because I don’t fully yet understand why IE isn’t loading the script files as the DOM elements are being added to the DOM, I’ll need to implement this for now. It does give me the advantage of knowing that any logic I do include via the package inclusion system, will be available after I have exited the call for that package.
If you have any idea behind the lower level occurrences here, please share. Till then, I got some re-writing to do.No comments