Taking Advantage of Closures in ECMAScript

I usually avoid nested functions (aka closures) like the plague. They just seem messy and there’s ample opportunity for memory waste. However, there are times when it makes perfect sense to use closures, such as when using them as event handlers for web service calls. Using closures makes understanding event flow, and therefore application logic, much, much easier. You don’t have to come up with unique names for a bunch of very similar methods and you eliminate scrolling all over the page to try and determine what happens when a web service call is made and a response is returned from the server.

Take a look at the image below. Notice how I’m registering an event listener and scoping it to a closure (nested function) within the method. When the asynchronous event is dispatched the mapped closure correctly catches the event and life proceeds beautifully. This is an example of closures and scoping working the way you would expect them to.

A couple of notes:

• Sho Kuwamoto did a nice write up on asynchronous event handling in Flex a couple of years ago, that I totally forgot about until writing up this blog post and looking for good reference material (too bad Sho isn’t with Adobe anymore — he was a killer resource).
• JavaScript folks should note that closures / inner functions work in their version of ECMAScript, though using a delegate to explicitly map scope is often necessary.

Lightroom 2 Beta – First Whiff

Lots of Adobe news lately and this time it’s the announcement of the Lightroom 2 public Beta available on Adobe Labs.

The first item to make an impact with me was the ‘getting started’ wizard you’re greeted by the first time you launch the application. Aimed at IUE (Initial User Experience), the getting started wizard is nothing new, but Adobe’s added a wrinkle — as you click through the wizard various elements described in the wizard are highlighted in the actual interface. It’s common to see lots of videos and written guides thrown at the user, so it’s nice to see the wizard be actually integrated within the projects. As a user I feel much more connected to the software and there’s no disjointing experience of having to switch between apps to view the IUE information.

Tight hooks into the application in order to provide IUE is something that Adobe’s latest efforts have put a lot of work into. Photoshop CS3 provides a ‘workspace’ which highlights elements that are new with the application as you work in it.

The other thing that jumped out at me was the location of the tools when in the ‘Develop’ module.

It’s way too late for me to stay up and play more, but John Nack gives the full run down on what’s new and improved.

MXML: Sweet, but Dirty

I’m not exactly sure why, but MXML kind of gives me a sickly sweet feeling. You know, the feeling you get from watching something that’s terrible, but beautiful (i.e. boxing). I really dig being able to lay out simple forms with a WYSIWYG editor, but I haven’t found too many cases where I can slide by with just MXML (ignorance on my part I’m sure) and that’s where the funk begins.

Here’s a short video (13 seconds) illustrating how to implement an interface in an MXML component.

Is it just me, or does it feel like the interface implementation should be a compiler directive set via metadata rather than a property? Having an ‘implements’ property in the markup is easy, but it somehow feels unnatural to me to be setting properties, binding variables and also setting compiler directives. I’ve come quite a ways with MXML over that last few months — my reaction has gone from alien to uneasy acceptance, but never to nirvana (I feel the same way about XAML — it’s seems awfully messy once you move beyond simple layout).

In the next example I have a custom MXML ViewStack component that contains a number of Canvas components (individual containers whose z-index is controlled by the ViewStack). A Dissolve transition object is also being declared and then bound to the showEffect trigger of each Canvas. Each time the view is reordered by the ViewStack the trigger fires and uses the Dissolve object to perform a tranistion.

Here’s the end result of this simple MXML effects binding. Click on the buttons to see the transition performed each time the ViewStack is reordered. Yah, yah, yah — the button bar is a bit long, but writing a custom extension that will allow multiple rows of buttons will have to wait for another day.

All of this fancy MXML coding is ultra cool, but it also hurts my ActionScript soul a bit; mind you, not enough to not bitch ferociously if you try to take it away from me. :)