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 (
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.
The Halo collection has its own
Button, as in Example 4-12.
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
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 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
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
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
This simple change lets you use
<gmap:Map/> instead of
<maps:Map/> in your MXML component declarations.