Problem Description

In MXML the id attribute is a special attribute. It is used to define the name of a generated property declaration on the underlying ActionScript class and it allows the property to be referenced in script and binding expressions.

However, if a type has an id property the developer may intend the attribute to represent a property assignment and not just as an identifier in MXML.

In Flex 4 we introduced an interface mx.core.IID that the developer must implement to instruct the compiler to generate an id property declaration. However, this requires a dependency on the framework.

Some classes, such as those in the Text Layout library, need the id property at runtime but they cannot depend on the Flex framework. Another scenario where the id property is needed at runtime is to style components using CSS id selectors.

Decision

Option 1.

Decision Criteria

The Advanced CSS code must be able to match components using id selectors at runtime, and the Text Layout library must be able to locate text nodes by id at runtime.

Proposed Solution(s):

Option 1. - Use Type Introspection (Opt-out via Namespaces)

Instead of testing that a type implements the mx.core.IID interface, the compiler instead checks to see if the type has a writable, public, non-static, id property of type String. If present, the compiler process the attribute as a property.

Note: this would only be done for MXML 2009 and later.

<s:MyClass id="123" />

If a suitable property was not found the compiler would simply not generate an id property. The id attribute would only serve as an MXML identifier.

To opt-out of this behavior the developer could prefix the id attribute with the language namespace prefix. The id attribute would only serve as an MXML identifier.

<s:MyClass fx:id="123" />

Option 1b. (Also Opt-out of MXML behavior via Namespaces)

For the sake of completeness we could also consider allowing the developer to opt-out of the MXML identifier logic by prefixing the attribute with the component namespace.

<s:MyClass s:id="123" />

If a suitable property was not found the compiler would generate an id property not found error.

Option 2. - Move Interface Outside of Framework

We simply move the mx.core.IID interface outside of the Flex framework so that it can be used without Flex. It would still require types to opt-in to the id property generation by implementing an interface.

Recommended Solution:

Option 1. or 1b.

Notes:

If we go with option 1, we should have a consistent solution for Application special attributes (frameRate, etc...) and the new states attributes (includeIn, excludeFrom, etc...)