The first theme is the idea of what Flex is. For every release up until this point there has been this concept of a namespace. We were required to declare the mx prefix and alias it to a URI for Flex. We have always done it, it was required, but not many have dug into what that is actually doing for us. At the bare minimum it references a manifest file which has a list of components that should be included in the library associated with the prefix. But at a deeper level you are also selecting what version of the MXML language you were using. Because in every single previous release there was only one MXML language available and one component set available for the release, we only had to declare one namespace. But in that regard Flex 4 is completely different. When you consider Flex 4 its not just one MXML version and one component library. In fact when working with the Flex 4 SDK you have three (3) languages (MXML 2006, MXML 2009 and FXG 2008 )available and two (2) visual component libraries (Halo and Spark) to choose from. The fact that we have lost that one-to-one pairing necessitates the use of multiple namespaces to make use of all these features. You will choose from the primary MXML language namespace and then potentially include a second namespace which accesses the component library of your choice. However the beauty of this is that MXML 2006 and MXML 2009 languages can be intermixed when using the Flex 4 SDK. The primary note to take away with theme 1 is the version of the framework you use is no longer as important to the version of the MXML language you choose as your base.

The second theme is about leveling the playing field around implementation. In the MXML 2009 language and in the Spark component set, I think the greatest achievements have been the ones that allow us to adapt and build components without having to override core built in behaviors. A perfect and wonderfully simple example of this is skinning. The skins for the visual components in Spark assign their initial UI in exactly the same manner we use to override it. That is the full visual implementation of a component is in a Skin class which we can copy, or completely replace. The life cycle for components has been adjusted so that we can very easily replace the built in skins with our owns, and we have been given the visual tools required to build those skins. In that same manner Adobe has opened the door for alternate UI frameworks to live right along side the built in Halo and Spark component sets. By separating the language from the list of component implementations you can now choose to use MXML with Spark and Halo, or with a completely separate UI framework like OpenFlux or OpenPyro. These UI frameworks can take full advantage of the MXML language for layout, but without having to be built on top of the existing Halo components to be displayed. This is an amazing treat and something that could allow us to truly take the Flex SDK and MXML as a language beyond the boundaries we currently abide by. It is completely feasible that we could create a component framework specifically for mobile that takes advantage of FP 10 in the browser of mobile handsets and through devices on the Open Screen Project.

In the end I think its important to keep in mind that Flex 4 is not just an increment in the version number. It is truly a step forward for the framework in terms of openness, functionality and design. The upgrade may cause some changing in how you relate to it, but it is all for the best.

Namespaces in Flex are the RIGHT decision. No matter how you look at it using namespaces to reference component libraries is how it is done, and how it has always been done. The difference is in Flex 4 you have options about what libraries you get to use. And the thing that you have to actually take into mind is that because of this option you may need to change the way you look at the code in the Flex SDK. Flex is not a language. The SDK has 2 languages that are used to compile content to SWF, those are ActionScript 3 and MXML. Building applications for Flex 4 means choosing which version of the compiler and the mxml language you wish to use, and then picking and choosing components from whatever UI library you wish (Halo or Spark).

Regardless of what the classes in Spark are named this would have been the workflow. To migrate an application from Flex 3 to Flex 4 you would have had to change all the namespaces in your application to the MXML 2009 namespace, and then added in the the new components you wished to make use of. The fact that the components in Spark don’t have names with superfluous extra characters would not have changed the workflow in the least. I have migrated apps to Flex 4, before the name change, during the time the classes were named poorly, and after. Because of the advances in the language, Flex 4 requires a new language namespace and allowing users to pick components from their choice of UI frameworks by using namespaces is invaluable.

So I am sorry Aral, on this topic I feel you are dead wrong. Namespaces are part of XML (and therefore MXML) and they are the correct way to make ambiguous nodes unique. A Panel is still a Panel regardless of how it gets skinned and giving it another name when there is already infrastructure for allowing the two to coexists would be an epic FAIL.

So again I want to say thanks to the Flex SDK team for not screwing up the language just for backwards compatibility sake. Once Flex 4 has been released and the upgrade path begins, people will be very happy that the classes they use are not misnamed. And new people coming to the language will not have to be explained to why the Flex 4 components couldn’t just be named what they are.

Elements in the language namespace are elements in mxml that can not be mapped to ActionScript components. These tags make up the base of the mxml language. In Flex 3 these tags included

• mx:Binding
• mx:Component
• mx:MetaData
• mx:Model
• mx:Repeater
• mx:Script
• mx:Style

These tags are what really make up the mxml language in flex 3. Every other tag you may have used was part of the halo component library or an AS3 class that someone had written (technically there are a couple compiler tags too, but we will skip those) All of these language tags are available in mxml 2009 with the addition of a few more including:

• Declarations
• Definition
• DesignLayer
• Library
• Private
• Reparent

Specifying the xmlns to either http://www.adobe.com/2006/mxml or http://ns.adobe.com/mxml/2009 you are choosing which version of the language you want to use. As you begin developing applications using mxml 2009 and the gumbo components you will find yourself integrating some of these new tags into your applications right away. For instance when declaring non-visual (classes that do not extend DisplayObject) items those must be instantiated inside the Declarations section of your application, or used in side a library element.

Beyond the additional tags that have been added to the mxml 2009 another key behavior has been modified. The default property metadata tag is no longer ignored when compiling your application. What this means is that if a class has a default property defined, any immediate children of the class will be interpreted as values for the default property. This is an amazingly powerful addition to the language because it means with some very minor changes as3 only frameworks can be utilized from mxml (but without the bloat of the flex framework).

I have some additional posts with examples of using the new elements coming in the next month. I just have to get through my family trip to Italy and my presentation at MAX Europe before I can finish them. With that… tune in next time for some more flex 4 fun.

But for more information on these new elements check out the MXML 2009 Specification Documentation on Adobe’s open source site.

An example of this is that while the earlier version of the sdk separated the language namespace and component namespace, those items have now been combined. So just like with flex 3 you must only specify the language URI to access all of the components in the language, halo, and gumbo namespaces.

My previous example has been updated below.

1
2
3
4
5

<?xml version="1.0" encoding="utf-8"?>
<Application xmlns="http://ns.adobe.com/mxml/2009" >
	<FxButton label="Gumbo Button"/>
	<Button label="Halo Button" />
</Application>

As you can see with the namespace prefixes removed there was a class name conflict between the Buttons in halo and gumbo. As a solution all of the gumbo components have now been named Fx[classname]. FxButton or FxCheckbox for example.

I hope this may help clear up some confusion around my previous post. It appears my timing could not have been better. No sooner had I written my post about the namespaces… they changed.