The Joy of Flex

Wednesday 2:30 pm. Blog is dougmccune.com. I make components.

Where do you start? Look at the Flex Framework! Thousands of lines of code. This is the most important resource for how to do Flex development. Really good code, solid standards, best practices for doing event dispatching, customization for styling, etc. In general you should try to follow that, make the code look like theirs. 243K lines of code, UIComponent alone is 8614 lines of code.

Adobe engineers are good, but they are not God. They are all just programmers like you and me. You can write better code than them. There is nothing magical in the framework. If a control doesn’t work for your UI, don’t use it, change it. Don’t settle for something bad.

Extend UIComponent: updateDisplayList(), createChildren(), measure(), commitProperties().

You can also do Sprite or MovieClip, but those are very different, they don’t go through the whole component creation, measure, etc. lifecycle. If you are doing something in an ActionScript project instead of a Flex project, you have to do it that way.

Why isn’t commitProperties() in the list of methods to override? probably it should be. Some people will do an initial implementation without a commitProperties override and then go back and optimize the component by moving things into commitProperties.

Communicating with events: for input, your components has methods and properties. For output, your component dispatches events and your component has bindable properties.

Good idea to use -keep-generated flag in the compiler and look at what code is generated when you use curly braces to set up bindings. A lot of stuff gets done for you and it’s a good way to understand it.

For styles, you should not rely on them being set. Follow the practice in the framework source and create public static consts for the default values, and use the static consts if the getStyle() call doesn’t return a value. All the classes in the framework have default styles in defaults.css.

Use the [mixin] metatag to a class and implement a static init() method, and the init() method will get called by the SystemManager when the SWF loads.

90% of Doug’s component development is overriding the framework. Don’t reinvent the wheel, just make it rounder. Take advantage of those 243K lines of code in the framework.

When the framework won’t play nice (private variables or methods), copy and paste the framework source, change private to protected, override the new class. This makes it easier to diff and merge your changes with the changes that come in the next drop of the framework.

“Underriding”. Say I don’t want to make my own component, I just want to implement it at the UIComponent level and have it affect all subclasses. You can do this. You probably shouldn’t because it might cause terrible unexpected problems, but you can do cool things with it if you dare and are willing to accept the consequences. You can implement a class called mx.core.UIComponent and it will bring in that class before the framework. Called “monkey patching” in other languages.

Demoed adding drag resize handles to every UIComponent subclass using this technique. It really works! Yikes.

Technorati Tags: 360Flex