We are asking Falcon to be able to generate code for both the current Flex SDK as well as the ASJS framework. One way to do that is to no longer generate the current Flex-oriented method for each MXML tag and instead generate a data structure representing each MXML tag and attribute. Code in each framework will interpret the data and "do the right thing". While object-literal or JSON-like data structure are easy to read and manipulate, testing showed they are much slower than the current generated methods, but a simple array of values is on par or faster than the generated methods. The array of values is not readable, but we can provide APIs to manipulate it safely for the few who might need to do it.

In the current Falcon code, the "new" generated code generates two arrays of values. One is called MXMLProperties which represents the attributes of the top-level tag in the MXML file, and the other is called MXMLDescriptor which represents all of the child tags.

The format for MXMLProperties is slightly different from MXMLDescriptor because it applies only to the top-level tag, it doesn't have to waste bytes specifying the object to apply the properties and styles to, or children tags since they are in MXMLDescriptor

There are 3 values per property or style or effects, and 2 values per event handler.

The list of properties, styles, effects, or event handlers first starts off with the number of properties, styles or effects.

The first value is the name of the property, style, effect, or event.

The second value is true if the third value is a simple scalar value (String, Number, int, Boolean).
The second value is false if the third value is an array of values representing an object instance.
The second value is null if the third value is an array of values describing an Array.

The third value is a simple scalar value or an array that will be decoded into an Array or an object instance.

In the MXMLDescriptor and in arrays describing object instances, the array starts with the class of the object to instantiate, and ends with an array of children for that instance or null.

In the properties list, the "model" property, if one is specified, always is first.

In the properties list, the "beads" array, if one is specified, always is last.

Example:

For the MXML

<Application width="100" height="200" >
   <layout><VerticalLayout gap="10" /></layout>
   <Button name="foo" color="red" backgroundColor="blue" click="someFunction()" />
   <Container name="bar" >
       <TextInput name="baz" width="400" />
   </Container>
</Application>

The MXMLProperties should be:

[ 3, // number of properties
  "width",  // name of property
  true,     // simple scalar value
  100,      // value
  "height",  // name of property
  true,     // simple scalar value
  200,      // value
  "layout", // name of property
  false,
  [ VerticalLayout, 1, "gap", true, 10, 0, 0, 0, null],
  0,        // no styles
  0,        // no effects
  0        // no event handlers
]

The MXMLDescriptor should be:

[ Button     // class for Button tag
  1,        // number of properties
  "name",  // name of property
  true,     // simple scalar value
  "foo",      // value
  2,         // number of styles
  "color",  // name of style
  true,     // simple scalar value
  "red',      // value
  "backgroundColor",  // name of style
  true,     // simple scalar value
  "blue',      // value
  0,        // no effects
  1,        // one event handler
  "click", // name of property
  generatedfunctionforeventhandler,  // the generated event handler
  null,    // no children
  Container     // class for Container tag
  1,        // number of properties
  "name",  // name of property
  true,     // simple scalar value
  "bar",      // value
  0,         // number of styles
  0,        // no effects
  0,        // no event handler
  [ TextInput, 2, "name", true, "baz", "width", true, "400", 0, 0, 0, null]
]
  • No labels

4 Comments

  1. What about databinding expressions?

  2. By separating MXMLProperties from MXMLDescriptor, you will subtly change the semantics of MXML. With non-descriptor-based instantiation, MXML treates children as if they were properties, so you'll be changing the order in which things happen.

  3. By having MXMLProperties have the properties first, then the styles, then the events, you are replicating an old MXML design which I think we should change (when we introduce MXML 201X). I think properties, styles, and events should get set in the order in which they are declared in MXML.

  4. Alex, are the above examples still "state of the art" wrt. FlexJS, or have there been changes in the data model since this was written? It seems like there are a few differences between the above description and what is output by FalconJS?