My First Flex 2 Framework

In order to build that audio framework mentioned earlier, a general-purpose foundation is needed for the sake of maintainability without sacrificing flexibility. It appears that the last three days of work yields what is needed!

To reach this particular location, a few landmarks were visited. These are:

• “Flex Quick Starts: Building custom components”—the code sample revealed a subtle either-or situation: either your component in MXML is called from an MXML application container or your component in ActionScript is called from the same container. Flex depends heavily on conventions—so the name of your tag in the calling container must match the file name of the component called. This crude barrier between MXML and ActionScript should be avoided.
• “Code-Behind in Flex 2”—Ted Patrick, an Adobe evangelist, borrows heavily from Microsoft—first by calling himself an “evangelist” and second using the jargon “code behind” to describe breaking down this ‘crude barrier’ between MXML and ActionScript. Unfortunately, I was unable to use flex2ant in eclipse to compile a project with this inheritance pattern (also the content assist fails for MXML in eclipse)—and, more importantly, inheritance reduces the flexibility of the MXML as, in this Ted Patrick example, it is a “sub class” to an ActionScript superior.
• “Flex Quick Starts: Building custom components” uses the same code-behind pattern as the one coming from Ted Patrick. You cannot say that Adobe is inconsistent!
• “ActionScript 3—First Steps XIV”—this post is the breakthrough! The effort here is to avoid MXML completely (which is not my design). The initialize attribute of the Application element is used to call a static method on a class in the code-behind package. This is similar to using the source attribute of the Script element but there are no upper-scope limits on the ActionScript called. You can view my interpretation of this minimal design at SonghaySystem.com.It was a small matter to take this minimal design and the information about components and move on to the problem of locating what Adobe calls “display objects” from the code “behind” the MXML. The Application object like all Container objects inherits the getChildByName() method. It is important to remember that casting is often needed with getChildByName() because it returns DisplayObject. It follows that:var myButton:Button = myCanvas.getChildByName('MyButton') as Button; The as operator is used here in a manner that I am accustomed to in C#. I’m assuming this is what is called “casting” in the Microsoft world but the Adobe documentation says:

Evaluates whether an expression specified by the first operand is a member of the data type specified by the second operand.

Actually, this Adobe definition of as helps me understand the Microsoft definition better! The Adobe use of the word “evaluates” adds just a little bit more to the Microsoft sentence, “The as operator is like a cast except that it yields null on conversion failure instead of raising an exception.” It is clear now that “conversion failure” can be the result of an “evaluation.”

But I digress—as programmers are wont to do…

Anyway—my Flex framework has these important characteristics:

• The strong names here are Client, component, lib and bin. The “Client” is obvious.
• The components are the loosely coupled things that are called by the “Client” and displayed.
• The “lib” refers to the generic libraries that are independent of the concern of the client and the components. Since flex depends heavily on conventions, using a folder called lib means that a “namespace” written as lib.* must be used. A future enhancement would be to use a linked folder to a centralized library for multiple Flex projects.
• The “bin” is where the SWF file ends up and sent out to the Web.Download this first framework sample at SonghaySystem.com. Note that this sample has been updated since it was first posted.

rasx()