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. :)