flex tips

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


« Previous Page