Creating a Frameworkless MXML File Part 2 (With Children)

6

Posted by ryan | Posted on 22-07-2008

Category : compiler, Flex, frameworkless mxml, MXML

In my last post, we saw how to use MXML (and Flex Builder) to instantiate one top-level object. However, to actually be useful, let’s learn how to add some children. There are two main ways to do this, through the IMXMLObject and through default properties. Both are pretty easy to understand.

Looking at the IMXMLObject interface, you’ll see one method:

package mx.core
{
 
/**
 *  The IMXMLObject interface defines the APIs that a non-visual component
 *  must implement in order to work properly with the MXML compiler.
 *  Currently, the only supported method is the <code>initialized()</code>
 *  method.
 */
public interface IMXMLObject
{
    //--------------------------------------------------------------------------
    //  Methods
    //--------------------------------------------------------------------------
 
    /**
     *  Called after the implementing object has been created and all
     *  component properties specified on the MXML tag have been initialized.
     *
     *  @param document The MXML document that created this object.
     *
     *  @param id The identifier used by <code>document</code> to refer
     *  to this object.
     *  If the object is a deep property on <code>document</code>,
     *  <code>id</code> is null.
     */
    function initialized(document:Object, id:String):void;
}
}

If your child object implements this interface, the MXML compiler will generate code to automatically call this method. It’s a pretty limited way to add children because it only has two properties, document and id. It actually doesn’t tell you who your parent is–just your document, which is your top-level root node object (usually Application).

Sticking with stupid-simple examples, I’m just going to draw some ellipses and rectangles. The code for drawing shapes has been ripped off of my co-workers, Chet Haase, and modified to make it as simple as possible and fit the example.

<?xml version="1.0" encoding="utf-8"?>
<components:MyContainer 
    xmlns:mx="http://www.adobe.com/2006/mxml" 
    xmlns:components="components.*" 
    xmlns:shapes="components.shapes.*">
 
    <shapes:Rect color="0xFF0000" startX="20" startY="20" endX="100" endY="30" />
    <shapes:Ellipse color="0x00FF00" startX="20" startY="120" endX="100" endY="130" />
</components:MyContainer>

Rather than post all the code here, I’ll just post some snippets (full code is in two flex builder projects: IMXMLObject example and the Default property example). The interesting part is ArtShape, which is the base class for all shapes. That class is the one that implements IMXMLObject, and all it does is:

public function initialized(document:Object, id:String):void
{
    document.addChild(this);
    renderShape();
}

So basically this initialized method just adds ourselves to the top-level application and calls a method that Chet had called renderShape(). The ArtShape version of that method is empty, but here’s what Rectangle looks like:

/**
 * Draws a rectangle into this shape's display list
 */
override protected function renderShape():void
{
    if (filled) {
        graphics.beginFill(color);
    } else {
        graphics.lineStyle(strokeWidth, color);
    }
    graphics.drawRect(startX, startY, endX - startX, endY - startY);
}

Looking at the generated code, you’ll see what’s going on behind the scenes with our MXML.

package 
{
//  begin class def
public class FrameworklessChildren
    extends components.MyContainer
{
    //  instance variables
/**
 * @private
 **/
    public var _FrameworklessChildren_Ellipse1 : components.shapes.Ellipse;
 
/**
 * @private
 **/
    public var _FrameworklessChildren_Rect1 : components.shapes.Rect;
    //  type-import dummies
    //  constructor (non-Flex display object)
    /**
     * @private
     **/
    public function FrameworklessChildren()
    {
        super();
        //    our style settings
        //    properties
        _FrameworklessChildren_Ellipse1_i();
        _FrameworklessChildren_Rect1_i();
        //    events
    }
    //  scripts
    //  end scripts
    //    supporting function definitions for properties, events, styles, effects
private function _FrameworklessChildren_Ellipse1_i() : components.shapes.Ellipse
{
    var temp : components.shapes.Ellipse = new components.shapes.Ellipse();
    _FrameworklessChildren_Ellipse1 = temp;
    temp.color = 65280;
    temp.startX = 20;
    temp.startY = 120;
    temp.endX = 100;
    temp.endY = 130;
    temp.initialized(this, "_FrameworklessChildren_Ellipse1")
    return temp;
}
 
private function _FrameworklessChildren_Rect1_i() : components.shapes.Rect
{
    var temp : components.shapes.Rect = new components.shapes.Rect();
    _FrameworklessChildren_Rect1 = temp;
    temp.color = 16711680;
    temp.startX = 20;
    temp.startY = 20;
    temp.endX = 100;
    temp.endY = 30;
    temp.initialized(this, "_FrameworklessChildren_Rect1")
    return temp;
}
    //  embed carrier vars
    //  end embed carrier vars
//  end class def
}
//  end package def
}

So basically to create the children it calls the methods in the constructor for the top-level root class. In those methods, the child object gets created, its properties get set, and the initialized method is called. The full code for the above example can be found here.

However, as I said before, this doesn’t really support nesting–these objects are essentially just direct children of the root object. So to support this, we need to use default properties. This is actually how the majority of objects will work in Flex 4 (Flex 3 essentially uses something else entirely which is built around UIComponents and UIComponentDescriptors).

Anyways, here’s our sample MXML file that we want to support:

<?xml version="1.0" encoding="utf-8"?>
<components:MyContainer 
    xmlns="http://ns.adobe.com/mxml/2009" 
    xmlns:components="components.*" 
    xmlns:shapes="components.shapes.*">
 
    <shapes:Rect color="0xFF0000" startX="20" startY="20" endX="100" endY="30" />
    <shapes:Ellipse color="0x00FF00" startX="20" startY="120" endX="100" endY="130" />
 
    <components:MyContainer x="100" y="100">
        <shapes:Rect color="0xFF0000" startX="20" startY="20" endX="100" endY="30" />
        <shapes:Ellipse color="0x00FF00" startX="20" startY="120" endX="100" endY="130" />
    </components:MyContainer>
</components:MyContainer>

You see I’ve added another container that has children. Another important thing to note is that I changed the compiler namespace to use the new 2009 namespace (so you’ll need the new compiler to take advantage of this). This isn’t actually needed, and I’ll show you what it looks like with just the 2006 namespace later on.

The basic idea of default properties is that every MXML object has a “default property.” In our case, MyContainer will have a default property of content. This is basically the property where the children go. Instead of the MXML code above, I could’ve used:

<?xml version="1.0" encoding="utf-8"?>
<components:MyContainer 
    xmlns="http://www.adobe.com/2006/mxml" 
    xmlns:components="components.*" 
    xmlns:shapes="components.shapes.*">
    <components:content>
        <shapes:Rect color="0xFF0000" startX="20" startY="20" endX="100" endY="30" />
        <shapes:Ellipse color="0x00FF00" startX="20" startY="120" endX="100" endY="130" />
 
        <components:MyContainer x="100" y="100">
            <components:content>
                <shapes:Rect color="0xFF0000" startX="20" startY="20" endX="100" endY="30" />
                <shapes:Ellipse color="0x00FF00" startX="20" startY="120" endX="100" endY="130" />
            </components:content>
        </components:MyContainer>
    </components:content>
</components:MyContainer>

The difference here is that when I instantiate MyContainer, I’m explicitly saying “fill the content property with these objects.” However, rather than having to explicitly say that the objects should be stuffed into the content property, I can tell MyContainer to have a default property of content. There was a bug in the MXML compiler in how it handled top-level default properties (only top-level ones), and that’s why I had to use the 2009 namespace to use it; however, if you explicitly specify the property, you can use the old compiler and the 2006 namespace.

So let’s see how we modified MyContainer to make this happen:

package components
{
    import flash.display.DisplayObjectContainer;
    import flash.display.Sprite;
 
    [DefaultProperty("content")]
    public class MyContainer extends Sprite
    {
        public function MyContainer()
        {
        }
 
        private var _content:*;
 
        public function get content():*
        {
            return _content;
        }
 
        public function set content(value:*):void
        {
            _content = value;
 
            if (_content is Array)
            {
                for (var i:int = 0; i < _content.length; i++)
                {
                    _content[i].initializeMe(this);
                }
            }
            else
            {
                _content.initializeMe(this);
            }
        }
 
        public function initializeMe(parent:DisplayObjectContainer):void
        {
            parent.addChild(this);
        }
 
    }
}

With the metadata, we defined MyContainer’s default property to be content. Then I just filled in some basic getters/setters for the property. Because content could be a single item or an Array of items, I special cased some logic in there. Basically all I did was loop through all the content and call initializeMe(this) on all the children. That’s just a method I made up, and I probably should create an interface for it. You can see I implemented initializeMe(parent:DisplayObjectContainer) in here as well, and all it does is call addChild. In the case of ArtBoard, it’s pretty similar:

public function initializeMe(parent:DisplayObjectContainer):void
{
    parent.addChild(this);
    renderShape();
}

So to complete the picture of how all this works, let’s take a look at the generated code for our MXML class (the first one which uses default properties):

package 
{
//  begin class def
public class FrameworklessChildren
    extends components.MyContainer
{
    //  instance variables
    //  type-import dummies
    //  constructor (non-Flex display object)
    /**
     * @private
     **/
    public function FrameworklessChildren()
    {
        super();
        //    our style settings
        //    properties
        this.content = [_FrameworklessChildren_Rect1_c(), _FrameworklessChildren_Ellipse1_c(), _FrameworklessChildren_MyContainer2_c()];
        //    events
    }
    //  scripts
    //  end scripts
    //    supporting function definitions for properties, events, styles, effects
private function _FrameworklessChildren_Rect1_c() : components.shapes.Rect
{
    var temp : components.shapes.Rect = new components.shapes.Rect();
    temp.color = 16711680;
    temp.startX = 20;
    temp.startY = 20;
    temp.endX = 100;
    temp.endY = 30;
    return temp;
}
 
private function _FrameworklessChildren_Ellipse1_c() : components.shapes.Ellipse
{
    var temp : components.shapes.Ellipse = new components.shapes.Ellipse();
    temp.color = 65280;
    temp.startX = 20;
    temp.startY = 120;
    temp.endX = 100;
    temp.endY = 130;
    return temp;
}
 
private function _FrameworklessChildren_MyContainer2_c() : components.MyContainer
{
    var temp : components.MyContainer = new components.MyContainer();
    temp.x = 100;
    temp.y = 100;
    temp.content = [_FrameworklessChildren_Rect2_c(), _FrameworklessChildren_Ellipse2_c()];
    return temp;
}
 
private function _FrameworklessChildren_Rect2_c() : components.shapes.Rect
{
    var temp : components.shapes.Rect = new components.shapes.Rect();
    temp.color = 16711680;
    temp.startX = 20;
    temp.startY = 20;
    temp.endX = 100;
    temp.endY = 30;
    return temp;
}
 
private function _FrameworklessChildren_Ellipse2_c() : components.shapes.Ellipse
{
    var temp : components.shapes.Ellipse = new components.shapes.Ellipse();
    temp.color = 65280;
    temp.startX = 20;
    temp.startY = 120;
    temp.endX = 100;
    temp.endY = 130;
    return temp;
}
    //  embed carrier vars
    //  end embed carrier vars
//  end class def
}
//  end package def
}

You can see it’s basically the same as the one using IMXMLObject; however, rather than calling the initialized() method for us, it just sets the content property. You can download the full code for this example here.

One thing that might be worth checking out is how this class gets generated in the first place. In the compiler, we have a few velocity templates that we use (for style sheets, MXML classes, binding, etc…). The one for the MXML->ActionScript is called ClassDef.vm (a lot of the methods used in that class exist in ClassDefLib.vm). If you’re interested in a lot of this stuff, definitely download the compiler code and take a look at these files. They’re pretty simple to follow and easy to modify if you want to start mucking around with it.

So that’s basically it for my short trip into compiler-land. If you’ve got any questions, let me know!

Creating a Frameworkless MXML File

3

Posted by ryan | Posted on 11-07-2008

Category : compiler, Flex, frameworkless mxml, MXML

Me saying it’s been a while since I’ve blogged here is an understatement. I’ve been heads down doing work on Flex 4, atleast that’s my excuse, and I’m sticking to it.

Along the way of deep-diving into the framework, I’ve learned how much of the nitty-gritty details actually work. Unfortunately, not all of it would be really valuable to you guys, but as I think of useful lessons I’ve learned, I’ll blog about them here.

Anyways, on to the real post: using the Flex Builder IDE and the MXML compiler for generating framework-less code. By framework-less code, I mean no mx.core.*, no SystemManager, no Application, no UIComponents, etc… So why would you want to do this? Let’s say you want to create something really light-weight and don’t want to carry around some of the framework baggage, but you still want to use FlexBuilder IDE because it’s made for programmers, unlike the Flash Authoring IDE. Or, you want to create an ActionScript only project, but love the MXML syntax because it’s a lot easier for non-progammers to take a look at the MXML code and figure out what’s going on. Some awesome features won’t be available if you don’t use the framework (for instance, binding), but this technique might prove useful to some.

At first, I didn’t know you could actually do this, but it’s quite easy. If you just have one file that is your main ActionScript file, in fact you don’t have to do anything. So let’s say I wanted to create a clock (and not a sweet analog clock, but just a digital one because I’m lame).

Pop open FlexBuilder and create a simple project. Create a simple class called SimpleDigitalClock.as. You’ve got to make sure it extends Sprite because in Flash, the root object must always be a Sprite. My primitive understanding of the reason is that every SWF must have a root object that needs to be a Sprite. This object will be instantiated automatically by the Flash player.

Our clock is going to be super-simple (I’m super-lazy). Here’s my version, but feel free to do something fancier with yours:

package
{
  import flash.display.Sprite;
  import flash.events.TimerEvent;
  import flash.text.TextField;
  import flash.utils.Timer;
 
  public class SimpleDigitalClock extends Sprite
  {
      public function SimpleDigitalClock()
      {
          super();
 
          time = new TextField();
          addChild(time);
 
          updateTime();
 
          timer = new Timer(1000);
          timer.addEventListener(TimerEvent.TIMER, updateTime);
          timer.start();
      }
 
      private var time:TextField;
      private var timer:Timer;
 
      private function updateTime(event:TimerEvent = null):void
      {
          time.text = new Date().toString();
      }
 
  }
}

As mentioned before I extend Sprite. In the constructor, I create a new TextField and add it as a child. Then I call updateTime, which grabs the current time and puts it into our TextField. Lastly, I just create a Timer which runs every second to update the time so it stays current.

Now for the cool part. Let’s say I wanted to make this my Application. Well it’s actually really easy, just change your main MXML file to look like this:

<?xml version="1.0" encoding="utf-8"?>
<local:SimpleDigialClock xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:local="*">
 
</local:SimpleDigitalClock>

When we run this file, and we get this beauty:

Digital Clock Screenshot

Some points to note:

  • We kept the mx namespace because the compiler needs this info, even though no components are instantiated from the mx namespace (hopefully I’ll talk about how this is done in another blog).
  • xmlns:local=”*” creates a new namespace, called local, which maps to actionscript files in my current directory.
  • All we need to do is tell the MXML compiler to instantiate our Sprite object, SimpleDigitalClock, as the root object for this SWF.

So that’s pretty damned simple. One of the things I often do is to delve into the compiled code. To do this, add “-keep” or “-keep-actionscript-generated” to the additional compiler arguments:

A new folder will popup called “generated.” This will be especially small because we’re using framework-less code. In fact, it’s only 2 files: FrameworkLessClock-generated.as and FrameworkLessClock-interface.as. Only the first one’s really interesting:

/**
*  Generated by mxmlc 4.0
*
*  Package: 
*  Class:      FrameworkLessClock
*  Source:     C:\Documents and Settings\rfrishbe\My Documents\Gumbo-FP10-MyBranch\FrameworkLessClock\src\FrameworkLessClock.mxml
*  Template:   flex2/compiler/mxml/gen/ClassDef.vm
*  Time:       2008.07.10 18:37:50 PDT
*/
 
package
{
 
import SimpleDigitalClock;
import flash.accessibility.*;
import flash.debugger.*;
import flash.display.*;
import flash.errors.*;
import flash.events.*;
import flash.external.*;
import flash.filters.*;
import flash.geom.*;
import flash.media.*;
import flash.net.*;
import flash.printing.*;
import flash.profiler.*;
import flash.system.*;
import flash.text.*;
import flash.ui.*;
import flash.utils.*;
import flash.xml.*;
import mx.binding.*;
import mx.core.ClassFactory;
import mx.core.DeferredInstanceFromClass;
import mx.core.DeferredInstanceFromFunction;
import mx.core.IDeferredInstance;
import mx.core.IFactory;
import mx.core.IPropertyChangeNotifier;
import mx.core.mx_internal;
import mx.styles.*;
 
 
 
//  begin class def
 
public class FrameworkLessClock
  extends SimpleDigitalClock
{
 
  //  instance variables
  //  type-import dummies
  //  constructor (non-Flex display object)
  /**
   * @private
   **/
  public function FrameworkLessClock()
  {
      super();
      //    our style settings
      //    properties
      //    events
  }
 
  //  scripts
  //  end scripts
  //    supporting function definitions for properties, events, styles, effects
  //  embed carrier vars
  //  end embed carrier vars
//  end class def
}
//  end package def
}

So you see not much happens. There’s a lot of comments in there for some framework stuff, but not much happens in our case because we don’t need that stuff. Let’s say you add event-listeners or properties to your SimpleDigitalClock. Those will get genned in here. So for a simple example, let’s create a property called timeZoneOffset, which will be the timezone offset (in minutes) that we want to change our clock to. I won’t go into the details of the math, but I think it works out… Also, let’s create a clockUpdated event, which dispatches anytime we change the text on the clock.

package
{
  import flash.display.Sprite;
  import flash.events.Event;
  import flash.events.TimerEvent;
  import flash.text.TextField;
  import flash.utils.Timer;
 
  [Event("clockUpdated")]
 
  public class SimpleDigitalClock extends Sprite
  {
      public function SimpleDigitalClock()
      {
          super();
 
          time = new TextField();
          addChild(time);
 
          timer = new Timer(1000);
          timer.addEventListener(TimerEvent.TIMER, updateTime);
          timer.start();
      }
 
      private var time:TextField;
      private var timer:Timer;
 
      public var timeZoneOffset:int = new Date().getTimezoneOffset();
 
      private function updateTime(event:TimerEvent = null):void
      {
          var date:Date = new Date();
 
          // converts the Date to UTC by adding or subtracting the time zone offset
          var currentOffsetMilliseconds:Number = date.getTimezoneOffset() * 60 * 1000;
          var newOffsetMilliseconds:Number = timeZoneOffset * 60 * 1000;
 
          date.setTime(date.getTime() + currentOffsetMilliseconds);
          date.setTime(date.getTime() - newOffsetMilliseconds);
 
          time.text = date.toString();
          dispatchEvent(new Event("clockUpdated"));
      }
 
  }
}

The two things that really matter here are adding the public property and the event metadata. We also dispatch the event in updateTime, otherwise it’d never get fired.

So let’s change these variables in MXML:

<?xml version="1.0" encoding="utf-8"?>
<local:SimpleDigitalClock xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:local="*"
  timeZoneOffset="480" clockUpdated="trace('blah')">

</local:SimpleDigitalClock>

Now, let’s take a look at our genned code from this example:

    //  constructor (non-Flex display object)
  /**
   * @private
   **/
  public function FrameworkLessClock()
  {
      super();
      // our style settings
      // properties
 
      this.timeZoneOffset = 480;
      // events
      this.addEventListener("clockUpdated", ___FrameworkLessClock_SimpleDigitalClock1_clockUpdated);
  }
  //  scripts
  //  end scripts
  //  supporting function definitions for properties, events, styles, effects
 
  /**
   * @private
   **/
  public function ___FrameworkLessClock_SimpleDigitalClock1_clockUpdated(event:flash.events.Event):void
  {
      trace('blah')
  }

You can see from the genned code it added the property we set as well as the event and a function for the event handler.
So that’s it for now. I plan on blogging some more on this stuff, covering how to add children in MXML without the framework as well as some other cool topics.

Post a comment if you have any questions or have suggestions future blog posts that might be useful.

Making Flex Menus Easier

25

Posted by ryan | Posted on 02-12-2007

Category : Flex, Menus, MXML

The Flex framework makes your life a lot easier when creating an application. However, not everything is necessarily as easy as it should be right out of the box;. Don’t fret though–there are extensibility points within the framework to make this job easier. One such particular example is Menus. So let’s look at a quick example:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
    <mx:MenuBar showRoot="false" menuShow="menuShowHandler(event)" itemClick="menuClickHandler(event)">
     <mx:XML>
      <menuitem id="rootMenu">
          <menuitem label="File">
              <menuitem id="menuNew" label="New"/>
              <menuitem label="Open"/>
          </menuitem>
          <menuitem label="Edit">
              <menuitem id="cut" label="Cut"/>
              <menuitem id="copy" label="Copy"/>
              <menuitem id="paste" name="paste" label="Paste" enabled="false"/>
              <menuitem type="separator" />
              <menuitem label="Other menu item"/>
          </menuitem>
          <menuitem id="windowMenu" label="Window">
              <menuitem id="d1" label="Document 1" type="radio" group="docs" toggled="false"/>
              <menuitem label="Document 2" type="radio" group="docs" toggled="true"/>
              <menuitem id="d3" name="d3" label="Document 3" type="radio" group="docs" toggled="false"/>
              <menuitem label="Document 4" type="radio" group="docs" toggled="false"/>
          </menuitem>
      </menuitem>
     </mx:XML>
    </mx:MenuBar>
 
    <mx:Script>
     <![CDATA[
      import mx.events.MenuEvent;
 
      private function menuClickHandler(event:MenuEvent):void {
       switch (event.label) {
        case "Cut":
         cutHandler(event);
         break;
        case "Copy":
         copyHandler(event);
         break;
        // many more cases if needed....
       }
      }
 
      private function menuShowHandler(event:MenuEvent):void {
       switch (event.label) {
        case "Edit":
         editHandler(event);
         break;
     // many more cases if needed....
       }
      }
 
      private function cutHandler(event:MenuEvent):void {
       trace("cut event");
      }
 
      private function copyHandler(event:MenuEvent):void {
       trace("copy event");
      }
 
      private function editHandler(event:MenuEvent):void {
       trace("edit event");
      }
     ]]>
    </mx:Script>
</mx:Application>

So you look at that, and it’s pretty damn easy to create a menu. You create a menu based off of a simple dataProvider that’s written in an easy-to-understand XML format. So what’s wrong with it? Well, I think there are a few problems:

  • The XML is untyped, so it’s easy to make a mistake or forget what the properties are (“type”, not “typed” and “toggle”, not “toggled”, etc…). It’s also easy to forget the values the properties take (for example: type takes check, radio, separator and not checked, checkbox, or something similar)
  • Databinding is not supported, so to disable the cut, copy, and paste menu items, we’d have to access the dataProvider for all three menu items and change it manually. We’d have to do this in a special method and remember to do it everytime, whereas if data binding was supported, it’d be done for us automatically when one property changes (for example, when a textarea has focus or something)
  • Events are global for the whole menu. It’s much better to attach events at the most specific point possible because we can avoid large, monolithic functions that essentially just dispatch the event somewhere else based on a large switch-case statement. Let the "framework" handle that for us.

Ok, so those are atleast some of the problems that I have with the current state of menus and specifying the data provider. However, we can fix these problems pretty easily. Since our data provider can be an object (not just XML), we can take advantage of this because MXML really just compiles down into an ActionScript object. Because MXML is essentially a typed object, we solve problem #1 (it can even tell us that type accepts check, radio, or seperator as inputs). Since MXML supports databinding, we solve problem #2, and with some functions of our own, we can define events on our new MXML object and get it routed to these more specific events and solve problem #3.

Here’s what the example above will look like when done:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" xmlns:local="*">
    <mx:MenuBar showRoot="false" menuShow="menuItemEventHandler(event)" menuHide="menuItemEventHandler(event)"
     itemClick="menuItemEventHandler(event)" itemRollOut="menuItemEventHandler(event)"
     itemRollOver="menuItemEventHandler(event)" change="menuItemEventHandler(event)">
     <local:MenuItem id="rootMenu">
         <local:MenuItem label="File">
             <local:MenuItem id="menuNew" label="New"/>
             <local:MenuItem label="Open"/>
         </local:MenuItem>
         <local:MenuItem label="Edit" menuShow="editHandler(event)">
             <local:MenuItem id="cut" label="Cut" itemClick="cutHandler(event)"/>
             <local:MenuItem id="copy" label="Copy" itemClick="copyHandler(event)"/>
             <local:MenuItem id="paste" name="paste" label="Paste" enabled="false"/>
             <local:MenuItem type="separator" />
             <local:MenuItem label="Other menu item"/>
         </local:MenuItem>
         <local:MenuItem id="windowMenu" label="Window">
             <local:MenuItem id="d1" label="Document 1" type="radio" group="docs" toggled="false"/>
             <local:MenuItem label="Document 2" type="radio" group="docs" toggled="true"/>
             <local:MenuItem id="d3" name="d3" label="Document 3" type="radio" group="docs" toggled="false"/>
             <local:MenuItem label="Document 4" type="radio" group="docs" toggled="false"/>
         </local:MenuItem>
     </local:MenuItem>
    </mx:MenuBar>
 
    <mx:Script>
     <![CDATA[
      import mx.events.MenuEvent;
 
      private function menuItemEventHandler(event:MenuEvent):void
      {
       if (event.item is MenuItem)
       {
        EventDispatcher(event.item).dispatchEvent(event);
       } 
       else if (event.menu && event.menu.dataProvider && 
          event.menu.dataProvider[0] is MenuItem && 
          event.menu.dataProvider[0].parent is MenuItem)
       {
        EventDispatcher(event.menu.dataProvider[0].parent).dispatchEvent(event);
       }
      }
     ]]>
    </mx:Script>
 
    <mx:Script>
     <![CDATA[
      private function cutHandler(event:MenuEvent):void
      {
       trace("cut event");
      }
 
      private function copyHandler(event:MenuEvent):void
      {
       trace("copy event");
      }
 
      private function editHandler(event:MenuEvent):void
      {
       trace("edit event");
      }
     ]]>
    </mx:Script>
</mx:Application>

You can see the code above looks basically the same, but it does solve all of our problems. We can even reference MenuItems by id’s now, treating them as first-class objects. The only tricky part is the menuItemEventHandler defined that you’ll also need. This grabs the appropriate MenuItem object and then dispatches the event to the event handler defined for that MenuItem. This is different then the switch-case statement above because it doesn’t actually know anything about our menu data — it just dispatched it through to the event defined on the menu item, so it’s the same for all menus.

So how was this so easily accomplished? Well it’s with a new MenuItem class. It’s basically just an object with some properites, like type, enabled, name, etc… and one important property, called children that’s an array of MenuItems. In its simplest form, MenuItem looks like:

package
{
 
    [Event(name="change", type="mx.events.MenuEvent")]
    [Event(name="itemClick", type="mx.events.MenuEvent")]
    [Event(name="menuHide", type="mx.events.MenuEvent")]
    [Event(name="menuShow", type="mx.events.MenuEvent")]
    [Event(name="itemRollOut", type="mx.events.MenuEvent")]
    [Event(name="itemRollOver", type="mx.events.MenuEvent")]
 
    [DefaultProperty("children")]
    public class MenuItem extends EventDispatcher
    {
         public function MenuItem() {
         }
 
         [Bindable]
         public var enabled:Boolean = true;
         [Bindable]
         public var toggled:Boolean;
 
         public var name:String = null;
 
         public var group:String = null;
 
         public var parent:MenuItem = null;
 
         public var label:String = null;
 
         [Inspectable(category="General", enumeration="check,radio,separator")]
         public var type:String = null;
 
         public var icon:Object = null;
         private var _children:Array = null;
 
         [Inspectable(category="General", arrayType="MenuItem")]
         [ArrayElementType("MenuItem")]
         public function set children(c:Array):void
         {
              children = c;
              if (c)
                   for (var i:int = 0; i < c.length; i++)
                        c[i].parent = this;
         }
 
         public function get children():Array
         {
              return _children;
         }
 
         // functions for manipulating children:
    }
}

Two cool things to note here are with the meta-data. The first is with [DefaultProperty("children")] defined above the class. This tells the compiler that when children are added in MXML, what property it actually correlates to. Another example of this is in the Flex framework for List and Menu where dataProvider is the default property. Another metadata trick is with [Inspectable(category="General", enumeration="check,radio,separator")] where we tell Flex Builder what the type property accepts so that code-hinting works quite nicely.

So the code above actually work perfectly fine, but I added some extra methods for dealing with children (adding, find, remove, etc…), which I will disclose aren’t tested very well. I’ve uploaded the full MenuItem.as code so you can download it. Mike Schiff, another Flex SDK engineer, was the first one to point out this technique, and his code was the basis for everything here (in fact, it was probably most of it).

This is a really simple technique but it helps with a few pits of creating menus in Flex. Not only that, but it can be applied to all components based on data providers. If you want to define a similar MXML object but want to have non-standard properties, like myType instead of type, you can tell the Flex framework this by using either dataDescriptor or something like labelField/labelFunction.