August 2007

The delete operator:
The documentation says the delete operator in reference to XML object can take an XMLList reference. In the initial outset this sounds fantastic because I can apply just about any searching algorithm (think regular expressions, descendants, etc), to a deeply nested object without having to traverse the entire object. However this simply is not the case.

One of the things that I’ve noticed that might catch a Java developer off guard, is the use of methods that expect a return type and the incorporation of try catch finally – throw statements. The Flex compiler at this time isn’t smart enough (or quite possibly by design), that it doesn’t detect when a throw statement is executed that it kills the execution thread.

One of the things that I’ve noticed with the SDK that is hit or miss, and can probably be attributed to a slew of different developers working on various aspects, is most event handlers are written in the private space especially if it’s a top level component.

This is not good design especially in light of the news that Adobe has announced it will make the SDK apart of its open source initiative with staring with Flex 3. The simple reason why is extensibility. Most projects are made up of at least 1 and probably up to several dozen custom components that extend off the SDK architecture. FlexLib is a prime example of this. With privatized event handlers, this makes it impossible to write an extended object that needs to intercept and enhance a given event. Duplicating the event by assigning the same event to a different handler achieves a work around however this essentially only adds overhead and to the overall confusion of trying to keep track of duplicated events.

Writing the handler to the protected space is a far better solution. It offers the same security protections of not allowing other objects to mistakenly execute the method, but allows the integration of an event hierarchy to become seamless. It also gives one added underrated benefit: event polymorphism. The encapsulating owner now has conditional execute privileges over the super method, which gives rise to writing controllers a lot easier to manage.

I’ll update this on an as I find them basis but here is a selection of hints, solutions, tips, etc. on some of the completely undocumented, or not so clearly documented either in the whitepaper documentation or in the SDK documentation.

  • mxml interfaces
  • mxml inheritance
  • verbose stack traces
  • gaining access to mx_internal


When I first started migrating some of my old AS2 code that I wanted to use and update for the AS3 world, these are some of the problems I have run across.

One of the biggest and most publicized differences in the new features is the access modifiers. There are some subtle differences here for those who have a Java background.


After switching host-providers, and general slacking off on my own site simply due to: just pure lazyness, it itself is not Flash oriented and the fact I sit in front of one of these all day doesn’t give me much motivation to do it yet again when I’m home.

The short of this is, as you might have guessed I am a Flex (Adobe Flex) Engineer, and I live and work in the greater Metro detroit area. I don’t know much anymore about web techonologies, html, much-less php and how it relates to blogs so this will probably always look a bit different than my main portfolio.

So, my intent with this is to anyone who is interested, is to show the sorts of things I have been recently working on, or the kinds of problems others may be facing and are desperately keyword hacking away at Google to find a solution someone else has come up with.