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="http://www.flensed.com/jquery.js"></script>
<script src="http://www.flensed.com/jquery.myplugin1.js"></script>
<script src="http://www.flensed.com/jquery.myplugin2.js"></script>
<script src="http://www.flensed.com/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
});Next up, I’m gonna talk about mpAjax, which allows for easy parsing of multi-part Ajax responses.
]]>For now, naturally, I have to replace all my old mobile applications with ones that will work for the Windows Mobile 6.1 Standard OS that Propel Pro runs. No small task as it turns out.
The real trick is that Propel Pro doesn’t run “Classic” or “Professional”, because it doesn’t have a touchscreen. This causes many problems with a lot of WinMob apps, because they are all written assuming a touch screen, and so those apps fail for those of us unfortunate (or fortunate, depending on how you look at it!) to not have touchscreens on our smart phones.
I’m particularly impressed by how usable the app is despite its “burden” of being without a touch-screen. On any tweet update, you can move the directional control left to do a “@reply” to the author, and right will give you a “RT @” retweet with the text already quoted. These two simple tasks have become so ingrained into DNA of what tweet’ing is about, it’s nice to see that they didn’t have to be buried in some menu option or rely on some fancy finger guesture to get at. They are quite literally at your fingertip, and I find that smart and well executed.
PS. Though this app unfortunately doesn’t do so (maybe they will, I can only hope!), if you are writing any kind of mobile app, you should be using PhoneGap!
]]>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.