I've been reviewing more options about handling dynamic loading of JavaScript in 5.4.
Based on this talk at Strange Loop (http://www.infoq.com/presentations/The-Once-And-Future-Script-Loader) I'm now leaning towards LABjs (http://labjs.com/), rather than RequireJS. I like RequireJS's approach to modules (AMD), but they aren't getting the right traction, with Bootstrap and Underscore actually removing support for AMD. I do want to craft an easy to use module system on top of LABjs, and I'm brainstorming what that might look like. Perhaps it would borrow from RequireJS and look something like: T5.define([".../xyz.js", "..../pdq.js", "some/other/module"], function(xyz, pdq, other) { ... return <an object or function> }); This would load xyz.js, pdq.js and some/other/module, and their dependencies, in parallel. When all was loaded, the function would be invoked. I'm not sure, what (if anything) would be passed for JavaScript libraries. Again, with the AMD setup, a object named module is placed in scope, and the "value" of the library is whatever is assigned, by the library, to module.exports. There might also be an option that would do the loading in parallel, but implicitly wait for the the DOM to be loaded before invoking the callback function. This is very close to the AMD specification; maybe there should be a T5.require() as well. Part of the overall goal here is to de-emphasize and eventually deprecate T5.initializers, and instead, make it easy to include a per-page or per-component JavaScript. I've also had some thoughts about a kind of "wrapper" that could be used to adapt a third party module so that it could be used in the module context: #include "some-library.js" module.exports = SOMELIB.noConflict(); In this wrapper mode, the library is included (as in a C language #include) to form a new virtual script, which is executed; the wrapper provides the extra logic to integrate the library into the module system. Another goal is to cleanly integrate CoffeeScript and Less and/or SASS. This has already been done by third parties (I don't want to look at their approach as it should be "clean room" for Apache). Option A. The CS and Less support is built right into tapestry-core. Advantage: easy way to use it ourselves: Disadvantage: tons of new dependencies for tapestry-core. Option B. The CS and Less support is an additional Apache module. Advantage: dependency control for end users. Disadvantage: can't use it in tapestry-core. Option C. Static CS and Less support as part of tapestry-* build, on top of option B. Advantage: we can use CS/Less in project. Disadvantage: complicated build, need to do something to regenerate when live coding the framework. I'd prefer A or C. C is more work, but may be the correct answer; for example, think what a disaster tapestry-yuicompressor would have been if it was built right into tapestry-core. -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
