Go vote for “Dude, where’s my UI architecture?” for SXSWi 2010!

This is a topic I’m very passionate about and I hope I can count on your support to help the talk get picked for the event. There’s over 3000 submissions for only 300 spots, so every vote counts!

Also, there’s lots of other great technical topics to vote on. I’ve started a list of a few I’m stoked about on this linked-in thread, so if you’re feeling generous, lend some votes their way as well.

Also, inspired by the code we worked out for the Mootools plugin, I have released updates to the jQuery plugin, Dojo plugin, and the Prototype plugin. These three plugins now play nicely with each respective framework’s built in error mechanism for normal Ajax calls.

Prior to this release, error handling was only possible by manually setting the “onerror” property in the flXHR instance configuration properties. This same functionality is still supported. But now the recommended approach is to specify your error callbacks directly in your Ajax/Xhr calls as you normally would. Note: Do only one or the other, not both, to avoid duplicate callback execution in some circumstances.

Now that flXHRproxy is more tightly integrated with each framework’s event mechanism, the ease with which you can make cross-domain Ajax calls just keeps getting better and better! Really, what excuse do you still have for not using flXHR for your next cross-domain Ajax call?

One last note: the jQuery update also includes one additional change. The “success” callback function signature is now extended to include a third parameter, which is set to the flXHR instance (XHR) that generated the call/response. This makes it much easier to determine which specific Ajax call the response comes from.

The first project is called LABjs (Loading And Blocking JavaScript). Put simply, this is a little tool (2.5k compressed) that lets you load Javascript assets dynamically, in parallel, but still allows you to define “blocking”, which is to wait for one or a set of scripts to load before executing other code, such as perhaps loading more scripts.

The main purpose of LABjs is to load scripts dynamically, in parallel, instead of old-school <script> tags which only load one at a time, and block everything else on the page. This significantly speeds up your page load. At the same time, you do sometimes still need to block and wait for some script to get loaded before doing other things. So, you get both in one simple loader API.

For instance, say you’re on a page that needs jQuery, but also needs a number of jQuery plugins. You need to load jQuery core itself, blocking on that download, and the ideally load all the other plugin files afterwards, in parallel, to get the page rendered and functional as quickly as possible. LABjs makes this type of functionality drop-dead simple.

So, this old style of <script> tags:

<script src="jquery.js"></script>
<script src="jquery.myplugin1.js"></script>
<script src="jquery.myplugin2.js"></script>
<script src="jquery.myplugin3.js"></script>

Becomes:

$LAB
.script("jquery.js")
.block()
.script("jquery.myplugin1.js")
.script("jquery.myplugin2.js")
.script("jquery.myplugin3.js")
.block(function(){
    // init myplugin1, 2, and 3
});

LABjs is now in v0.7, and is demo’d and hosted on: http://labjs.com.

As I said, this type of loading logic is powerful and clean, and will probably replace the code loading logic in flensed/CheckPlayer/flXHR projects for their next releases.

Joe McCann wrote a great blog post describing and showing off the LABjs tool.

Next up, I’m gonna talk about mpAjax, which allows for easy parsing of multi-part Ajax responses.

Austin resident Prototype guru Andrew Dupont recently wrote an initial version of the plugin, which I then modified and tested, and we now have a great plugin for Prototype to support flXHR in the same way as the other frameworks.

Just like with the other framework plugin versions, you simply call ‘registerOptions(…)’ to register a URL (or partial URL) destination target and a set of flXHR options to be used for that location. Then, when you later make various Ajax calls, Prototype will internally figure out if you are calling to a location that is registered and will use flXHR with the options you specified.

There is simply no other way to get easier cross-domain Ajax with Prototype than with flXHR and flXHRproxy. Take a look at flXHRproxy documentation or give the Prototype+flXHR demo a whirl.

Typical page usage might look like this:

Ajax.flXHRproxy.registerOptions('http://www.mydomain.com/',{xmlResponseText:false...});
Ajax.flXHRproxy.registerOptions('http://rss.mydomain.com/',{xmlResponseText:true...});
...
Ajax.Request('http://www.mydomain.com/something.html',{...});
...
Ajax.Request('http://rss.mydomain.com/feed.html',{...});


Enjoy the new world of possibilities and fun that Prototype and flXHRproxy now gives you for doing easy cross-domain Ajax!

Building on the success from the jQuery plugin, I’m now pleased to announce that I’ve released a Dojo plugin for jQuery which is nearly identical in functionality. Basically, all you have to do is load the ‘flXHRproxy’ Dojo plugin, and then call ‘registerOptions(…)’ to register a URL (or partial URL) destination target and a set of flXHR options to be used for that location. Then, when you later make various Ajax calls, Dojo will internally figure out if you are calling to a location that is registered and will use flXHR (or any other transports you register!) with the options you specified.

If you use Dojo, and you do cross-domain Ajax calls, I urge you to consider flXHR and flXHRproxy. Take a look at flXHRproxy documentation or give the Dojo+flXHR demo a whirl.

Typical page usage might look like this:

dojox.io.flXHRproxy.registerOptions('http://www.mydomain.com/',{xmlResponseText:false...});
dojox.io.flXHRproxy.registerOptions('http://rss.mydomain.com/',{xmlResponseText:true...});
...
dojo.xhrGet({url:'http://www.mydomain.com/something.html'...});
...
dojo.xhrGet({url:'http://rss.mydomain.com/feed.html'...});


This XHR registry concept is very powerful, as it allows you to have multiple different types of Ajax calls and transports and configurations for different types of data that you are mashing up in a single page. It takes all the guess work out of configuring your code to intelligently use the right communication method and options as needed for each Ajax call. It just simply could not get any easier to do cross-domain Ajax calls with Dojo now.

Enjoy the new world of possibilities and fun that Dojo+flXHR now gives you for doing easy cross-domain Ajax!

PS. Teaser: Coming soon, flXHR+YQL = cross-domain Ajax to literally any site on the internet! How cool is that!?