Flex 4: New MXML States Specification
May 9th, 2008 Posted in Flash Player, Flex Development, Rich Internet Applications
Ted over at OnFlex posted a link to the new Flex 4 MXML states spec and I sat down to read it. After finishing the spec, I thought long and hard about it and finally decided to add my own thoughts about the new spec to their wiki. It is really awesome that Adobe is starting to open up the specs to the public. It gives developers a chance to see where the technology is going and also allows them to give feedback to the team. Anyway, I am reposting my comments here so that you all can see what I had to say:
After my first in-depth pass of the spec I have some concerns around the developer workflow and the possible complexity of the MXML generated with the new inline states. I agree that the current Flex state mechanism is hard to read, limited and can be overly complex to follow. Looking at the new proposed methodology I feel the solution has the potential to become just as complex, if not more so, and could make the code harder to follow for developers with larger components. An example of this kind of complex situation would be creating large forms that dynamically change their field structure dependent upon how the user answered previous fields in the form. On a project I worked on we relied heavily on states to solve this issue because we constantly had to show/hide fields and extend forms based on the user selections.
My first concern is that by moving into an inline methodology making changes from code view becomes harder to traverse and manage overtime. The new inline syntax requires the developer to look for state properties and tags within the whole of the MXML layout to determine what is being show when and where. One of the benefits of the current syntax is that each state node clearly (more or less) shows what happens when each state is selected. With the new syntax the developer has to comb over all the code and then attempt to find all the references that define state layout. In many situations this can be overcome by componentizing the code to help alleviate the complexity of the MXML but with large forms this is not necessarily an easy or viable solution.
My second concern is based around state inheritance. I see that I can set includeIn/excludeFrom to multiple states or groups, but this means that I have to track all of the reparenting inline vs. using the classic “basedOn” inheritance approach. A benefit of the inheritance model is that if state A handles a complex reparentaing structure and state B is a simple change to state A, a developer can simply state the changes in state B and then say extend from state A. With the new syntax, a developer has to track all the iterations of A and verify that B is added to all the state A changes and then make sure the B changes are applied.
As you can tell, both of my concerns are focused on codebase management. With the push of RIA development we are now creating code bases that have to grow, mature and scale over time. The focus of maintenance and team growth on a project is becoming more important for development teams and as new developers are brought into the code base, readability and ease of maintenance is very important. If a new developer was assigned to edit a form using the new layout they would have to review all of the MXML layout to determine both how it is structured and how it evolves with state changes. If this state management is defined outside of the layout then in some ways it is easier to determine what is changing and when. I fully realize that the current states model needs to be redesigned but I feel moving to 100% inline solution is not necessarily the best answer and possibly a hybrid approach could help help manage code readability.
Part of my passion about states is that I was the QA engineer assigned to the first iteration of states when we were developing them for Flex 2. States are one of those concepts that are hard to grasp at first but then make a lot of sense and are incredibly useful after you get it. In fact, we used states all over the place on Scion.com and I think all of the dev team learned to both love and hate them. Let me know what you think about the proposed changes and if you feel strongly one way or the other I highly recommend commenting directly on the Flex spec!
One Response to “Flex 4: New MXML States Specification”
By webnesto on May 12, 2008
It’s funny to me that form elements have been around in internet technology for this long and yet, to most WITHIN THE INDUSTRY the inherent complexity of forms is still often overlooked.
Complex form flow created in such a way as to be easily maintainable and reusable is extremely difficult, no matter what the tech.
That being said, I think that states in Flex is one of the most efficient tools available to developers to address this particular problem. The thought that the Flex team would mess that up, is very disheartening.
I understand the challenge: how to make states easy to use AND as robust as necessary.
Now that I think about it, if Adobe were to provide a flex library/UI for creation of form-flow (I guess it would be useful to define what I mean by form-flow: form elements that determine the presence of or the validation rules of subsequent form elements) in a reasonable to use interface, I guess I could be content with a variety of ways that could be implemented. But only if it was rock solid and easily editable (from either a GUI or code approach). Having tried to create the logic structure behind such a tool myself, I can honestly say that it is an extremely large challenge. It seems simple (and is), right up to a single jump in complexity, that immediately takes it into the realm of nigh-impossible.
Anyway, yeah… I agree with your concerns and appreciate (as always), you watching out for the developer in the street. Those of us with no patience for reading tech-specs would never have known about this if not for your timely reporting.