Ted Patrick has a post up on his blog about a new feature in Flex 4 that will allow for state-specific variables to be nested in individual components. Ted claims that in Flex 3 and below, States have been too hard to use and edit outside of the "design view" (someone uses the design view?), so an effort has been made to simplify them. The new code posted on Ted's blog looks something like this:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="library:ns.adobe.com/flex/halo"
xmlns:m="http://ns.adobe.com/mxml/2009" layout="absolute">

<mx:CheckBox label="Submarine" color.waterState="0xFF0000"/>
</mx:VBox>
</mx:Application>

I'm sure this will go fine, but as a person resistant to any language change that can create bad code, I'm worried about how many of these state-specific variables we're going to see. Imagine if one of his check boxes was written like this:

<mx:CheckBox id="changeWithState" color.waterState="0xFF0000" color.landState="0xF0F000" color.airState="0xFF0000" />

Now, this is no big deal, but if we add a few more states, it'd get unwieldy. And we really wouldn't want these colors hard-coded into the MXML, which means should be assigned on a model somewhere, so now the code looks like this:

<mx:CheckBox id="changeWithState" color.waterState="{Model.WATER_COLOR}" color.landState="{Model.LAND_COLOR}" color.airState="{Model.AIR_COLOR}" />

And this is probably even worse, because MXML doesn't distinguish between assigned data and bound data, so all of these colors are bound to the model whether we need it or not creating a slough of meaningless getter and setter methods that our compiler will have to sludge through.

In my opinion, a better way to assign these properties would be in ActionScript, where the code is more clear and no binding is required. All our MXML would bind to is a single model object, like this:

<mx:Model id="checkBoxStateModel">
<color>
<airState>0xff0000</airState>
<waterState>0x00ff00</waterState>
<landState>0x0000ff</landState>
</color>
</mx:Model>

<myCode:StatableCheckBox id="changeWithState" stateModel="{checkBoxStateModel}"/>

Then write your checkbox in actionscript to parse it's model, subscribe for a parents' stateChange events, and adjust it's properties accordingly. A base "statableObject" class could be written to handle the state-parsing and property-updating and be reused in multiple places.

I like this solution better for a number of reasons: it keeps our MXML cleaner, makes a cool reusable "statable" object, and allows us to externalize the state-specific data in a model object without adding lots of unnecessary binding to our code.

Have said all of that, I guess Ted's solution is still a huge improvement over the current slough of "addChild" / "removeChild" tags that states require.