O'Reilly logo

Learning Flex 4 by Elijah Robison, Alaric Cole

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

S, FX, and MX: Namespaces Explained

Flex 4 provides three packages of components, and each is identified by a unique namespace. The three Flex 4 namespaces are Spark (s:), Halo (mx:), and the Language (fx:) namespace.

Each MXML component tag should contain a namespace designation, like the Button tag in Example 4-11, which declares the Button component from the Spark collection.

Example 4-11. An MXML Button in the Spark (s:) namespace

<s:Button/>

The Halo collection has its own Button, as in Example 4-12.

Example 4-12. An MXML Button in the Halo (mx:) namespace

<mx:Button/>

The same syntax is used to declare components from the Language (fx:) namespace, as shown in Example 4-13.

Example 4-13. An Array declaration in the Language (fx:) namespace

<fx:Declarations>
    <fx:Array id="statesArray">
        <fx:Object>Alabama, AL</fx:Object>
        <fx:Object>Alaska, AK</fx:Object>
        <fx:Object>Arizona, AZ</fx:Object>
        <fx:Object>Arkansas, AR</fx:Object>
    </fx:Array>
</fx:Declarations>

Namespace Basics

What’s a namespace? Take a look at the word itself: name + space. Basically, a namespace is a package designation for a prebuilt set of components. You can illustrate this concept in Source mode by typing <s:Bu, and noticing that you have two Button options to choose between, as shown in Figure 4-4.

Button controls in the Spark (s:) and Halo (mx:) namespaces—the choice is yours

Figure 4-4. Button controls in the Spark (s:) and Halo (mx:) namespaces—the choice is yours

The Button class has been around for a while and continues to be important. Therefore, it exists among the new Spark components as well as the older Halo components. We recommend you use the updated Spark component, but because both packages are available within Flex 4, it’s your choice. Similarly, you could create an extension of the Spark Button that includes a few specialized properties and save it in your own package/folder. To use the extended button in your project, you’d have to assign your custom package a namespace declaration. Custom namespaces are pretty common, even among small applications.

Most simply, namespaces point to component locations within a package structure. They may identify components in precompiled libraries (SWC files), or they may represent a classpath in your project’s src folder.

If we revisit the concept of extending a Button, you could still name it “Button” because your unique namespace would distinguish it from its Spark/Halo counterparts, and the source code for your class would exist in a unique directory. You might then refer to your button in MXML as something like <tweaks:Button/> to differentiate it from <s:Button/> or <mx:Button/>.

Namespaces and Third-Party Libraries

If you work with a third-party library, code completion will add the library’s namespace definition for you as you add components from the third-party library. For example, if you download the Google Maps API (it’s a SWC) and add it to your libs folder, typing <map is enough for code hinting to lead you to <maps:Map/>, and in turn, Flash Builder will create the Google Maps namespace, as shown in Example 4-14.

Example 4-14. A third-party library with a unique namespace identifier

<s:Application
    xmlns:fx="http://ns.adobe.com/mxml/2009"
    xmlns:s="library://ns.adobe.com/flex/spark"
    xmlns:mx="library://ns.adobe.com/flex/mx"
    xmlns:maps="com.google.maps.*"

But what if you don’t like that default namespace? Why not change maps to some other identifier? Well, you can.

Note

If you spend much time dabbling in third-party libraries, you’ll frequently encounter the convention com.domain.subpath.* among package structures. The technique is called reverse domain package naming, and developers endorse it for two reasons. First, and most significantly, this strategy helps to keep component packages in unique classpaths, serving the purpose of avoiding class name conflicts. Second, well, there’s a clear marketing advantage.

Note the line xmlns:maps="com.google.maps.*". This is easy to customize. For instance, instead of maps, you could use gmap, as demonstrated in Example 4-15.

Example 4-15. Changing a library’s namespace

<s:Application
    xmlns:fx="http://ns.adobe.com/mxml/2009"
    xmlns:s="library://ns.adobe.com/flex/spark"
    xmlns:mx="library://ns.adobe.com/flex/mx"
    xmlns:gmap="com.google.maps.*"

This simple change lets you use <gmap:Map/> instead of <maps:Map/> in your MXML component declarations.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required