Problem Description

Developers are confused by the states and State tags in Spark/MXML 2009.  Both tags can appear in both the spark and halo namespace.  Sometimes, the states tag can appear in other namespaces (based on the root tag of the document).  But developers generally think of states as a language feature, not a component feature. In fact, it almost entirely is...the compiler makes heavy use of the states and State tag to determine what state decorators are legal elsewhere in the document, and generates special code based on their content.

 However, states are implemented today via a states property on UIComponent.  This property can't go away -- it needs to remain for backwards compatibility with code built on previous releases of Flex.

How do we reconcile the legacy states implementation with its new role as a language feature without confusing the developer?

Decision

Decision Criteria

Developer confusion:  which solution will make the most sense to the developer in day to day use, regardless of the underlying implementation?

Long term Scalability:  Will the solution create performance problems in the tool or the compiler? Will the implementation create unmaintainable codepaths? 

Proposed Solution(s):

Option 1: hiding the property

  1. add a new special language tag, called "fx:states"
  2. move the State object into the fx namespace
  3. have the compiler key off this new fx:states tag
  4. Hide codehinting in MXML for the mx/s states property defined on UIComponent.

Option 2: Deprication

  1. add a new special language tag, called "fx:states"
  2. move the State object into the fx namespace
  3. have the compiler key off this new fx:states tag
  4. Introduce a new non-property based set of APIs on UIComponent for applying a set of state objects.
  5. Depricate the existing states property. The deprication warning would re-direct to the language tag and the new API.

 Option 3:  do nothing

Keep the states tag out of the language.  It's worked up till now, it will continue to work.

One or more possible solutions that are worth considering

Recommended Solution:

Option 3.  We believe that the current situtation, while slightly confusing to some users, would be just as confusing to others if we placed states and State in the fx namespace, and in the end, add little value.  Codehinting will go a long way to prevent the user from even having to think about the namespace. 

 Furthermore, even if we put states in the fx namespace, we'd still have to allow it in specified as a property, since it is still a legal settable property on the root tag.  Which means if we do nothing now, and find that it continues to be a problem, we can make the change at a later date without creating further backwards compatibility problems.

Notes: