Flash Builder 4 inline syntax for states looks slick but encourages bad behavior
I’ve been gearing up to dive into Flash Builder 4 and have read a couple of articles about its new features. One that caught my attention was a new, inline syntax for referring to states, e.g., <s:Button label.A="Button" label.B="State B" includeIn="A,B" />, to switch the label for the button depending on the current state (A or B). As Jon Rose explains it:
The legacy state syntax in Flex 3 required components and properties to be modified within the state block. This was out-of-context, often verbose, and frequently confusing. Flex 4 introduces a new inline syntax that is both flexible and terse.
Not to single out Jon, because I saw it in other articles as well, but it points to a lack of understanding of one of the strengths of a state-based approach: all the code for a state is contained in the same location, and hence it is much easier for the developer to understand what the application does in that state. The new, inline syntax for states allows developers to sprinkle behavior related to different states on the same element, which means if one wants to understand the overall behavior of a state, one has to examine all the potential elements.
I was particularly struck by Jon’s comment that because “Flex 3 required components and properties to be modified within the state block”, it was “out-of-context” and “frequently confusing”. That sounds strange to me, because requiring changes to be enclosed in the state block actually is the correct context, namely things that happen in that state, where one looks for information about how that state behaves!
Admittedly, I have not really worked in Flex 3 or Flex 4 (yet), but I believe the concept of states should transcend the development platform. Therefore, I have to give a ‘thumbs down’ to this new inline syntax for states.
4 Comments »
Leave a comment
Recent Appearances
FlashSim Blog 
The states syntax in FX2&FX3 was very hard to read and extend. As all state changes occurred in blocks, describing the delta changes on many components got very complex and hard to maintain. Being able to denote states where components are instanciated makes it much easier to edit given the location of the state values is on the instance itself. It also allows for more incremental change.
I stopped using States at FX2.2 because the syntax was so hard to maintain. The new syntax makes it much easier overall and I feel it adds much value to Flex4. I know we can debate this round and round but go build and app using states in Flex 3 and Flex 4 and you will see this super clear.
My take is that it is a great change.
Ted 🙂
I’d love to discuss this more if we have a chance to meet sometime, maybe at MAX.
One comment, though — you mentioned the “delta changes on many components” — this seems to me you’re suggesting the behavior of a component could depend on how that component has been changed over the history of states that have been visited. This is a big no-no in terms of state machine design, as each state is supposed to be a complete context. The explosion of states is one problem with FSM’s being used practically in large systems.
I am eager to get into FB4 and adapt my hierarchical state machine (HSM) work to it, so hopefully we can have a good discussion at the next opportunity.
Hey Jon,
I think there may be a misunderstanding here since States for components are not part of a state machine. They are more about a component being in a visual state, e.g., up or down, selected, etc. Given that these tend to be minor adjustments and not wholesale replacements, making it easier to include deltas as close to the actual component declaration as possible I think is a lot easier to understand. We’re pretty excited by this change, we think a very useful feature will now finally get used 🙂
Matt
Thanks for the clarification, Matt. I didn’t intend to be picky, and I see wonderful things in FB4 that make me wish I had more time to explore (though alas, life intrudes)!
Rather, since I spend a lot of time developing applications that use state machines (finite state machines and hierarchical state machines), I wanted to point out the potentially-dangerous path one might go down by subordinating to elements the behaviors for specific contexts/states, thereby diluting the critical organizational benefit of using a state-based architecture.