curl.js with IE10!

45 views
Skip to first unread message

unscriptable

unread,
Oct 23, 2012, 10:32:32 PM10/23/12
to cuj...@googlegroups.com
Just a reminder: IE10 is being released in just a few days!

The following versions of curl.js are known to work with IE10:


unscriptable

unread,
Oct 24, 2012, 8:03:56 AM10/24/12
to cuj...@googlegroups.com
The reason there are three different versions: over the past few release cycles, we've been refactoring curl from a url-based cache to an id-based one.  While an id-based cache is absolutely critical for building apps that use multiple bundles (aka "optimized files"), it isn't necessary for apps that don't do any bundling whatsoever.  

If you're coming from requirejs, you probably already instinctively organize your modules into package-like folders and require() them using "package/id" semantics.  However, some people may be letting url-ish bits get into their module ids.  curl.js has started migrating away from allowing url-ish bits in ids since 0.6.3.  Version 0.7.0 limits this even further -- but doesn't allow some valid configurations for plugins, unfortunately.  We're working on 0.7.1 that has new features that work-around these issues and has substantial documentation to help you understand the situations that require you to remove the url-ish bits from your ids.  

Example of letting url-ish bits get into your module ids:

// myApp/views/moduleA
// note that the util dependency has path bits that extend out of the current myApp "package".
// curl will assume you're intending to fetch a module by its url, not its id:
define
(["../../lib/util"], function (util) {});

In the example above, curl can't resolve "../../lib/util" against the parent module's path, "myApp/views/moduleA" since it navigates up too many levels (too many "..").  curl 0.7.0 would throw an error in this case.  curl 0.7.1 will assume you're bypassing the paths/packages configurations and specifying the url of a module.  This really is user error, but we probably shouldn't be throwing.

Valid use of url-ish bits:

// myApp/views/moduleA
// since we're keeping our css in a separate code-base, we need to extend beyond baseUrl
// to fetch stylesheets:
define
(["ccs!../../../css/my-app.css"], function () {});

In the example above, curl 0.7.0 would consider the attempt to navigate out of the package as an error.  In curl 0.7.1, this will work fine.

I don't have time this morning to explain why url-ish bits will screw you when you start bundling your files using r.js or cram.js.  Like I said, documentation is coming! :)

-- John
Reply all
Reply to author
Forward
0 new messages