Metaphorically, think of MXML as the skeleton within the body of your source code. Just as skeletons provide structural definition to our human bodies, MXML code gives your project a visible structure.
You’ll quickly adapt to MXML syntax because it’s so intuitive, but a few details should be covered now to guide your thinking.
XML stands for Extensible Markup Language. Extensible refers to the capacity to create your own tag relationships. Markup means your tags can include text as well as extra information about that text, also via tags. Remember, tags are identified by their <opening> and </closing> syntax.
XML is not a programming language. Rather, XML is a structured arrangement of text and data. There are no keywords, component classes, class properties, or methods. It’s simply textual information presented according to specific syntax rules that identify a hierarchy or relationship between the elements. So how do XML and MXML compare?
MXML borrows its syntax rules from XML. However, to the Flex compiler, MXML identifies ready-made ActionScript classes that can be instanced using XML syntax. In this way, MXML is essentially a class vocabulary that provides a more convenient approach to declaring ActionScript UI components.
As we just discussed, XML is simply structured text. It distinguishes data structures within tags defined by angle brackets (
>). There isn’t an XML vocabulary of reserved words; in fact, the author of XML is free to create her own structural hierarchy. So, XML is purely syntax and structure.
You’re reading a book right now, so you recognize that a book is divided into chapters and sections. If you wanted to represent a book in XML, you could create tags like
<section/>, and deploy the book like Example 4-5.
Example 4-5. Empty XML demonstrating structural hierarchy
<book> <chapter> <section/> </chapter> </book>
As implied by this example XML, “book”—the root node—contains “chapter” nodes, which contain “section” nodes.
XML parsers, including Flash Builder, web browsers, etc., are unforgiving when it comes to XML syntax. While you can invent whatever tags and data structure you desire, you can’t invent your own syntax rules. So let’s discuss the basics of XML syntax.
An important fact about XML is that each tag must be complete. If a tag is opened, it must eventually be closed later in the XML. As you’ve seen, an XML tag is opened with a left bracket (
<), some text representing the tag’s name, and then a right bracket (
>). To maintain our previous example,
<book> is an opening tag. Finishing the tag requires closing it using a forward slash (
/) in the proper position within the closing tag,
You can ensure all tags are closed in a couple of ways. The first is by creating the end tag immediately after you create a beginning tag. So, after creating the open container tag
<book>, go ahead and create the closing tag
</book>. Alternatively, if a tag will not have any nested tags—as is often the case with simple Flex controls such as the
CheckBox, and others—you can use shorthand syntax by adding a forward slash immediately before the right angle bracket of the opening tag, like this:
<section></section> is equivalent to
XML is case-sensitive. That is to say, uppercase letters and lowercase letters distinguish different elements. So,
<Book> aren’t the same in XML. That means
<s:text> are different as well.
The first line of an XML document may optionally contain a line declaring it as XML and listing what encoding it uses. The declaration looks like the line in Example 4-6.
Encoding in this context refers to your potential to use various characters and symbols in your XML markup. There are different encoding standards available to you, but
utf-8 is the way to go. For more information, see the w3schools discussion of this topic at http://www.w3schools.com/XML/xml_encoding.asp.
All MXML files created through Flash Builder automatically contain this XML declaration, so you don’t need to worry about creating it.
Because MXML is XML, MXML inherits all the XML rules.
Make sure you don’t have any spaces, empty lines, or other whitespace before the XML declaration in a Flex application. Otherwise, Flex will warn you that whitespace is not allowed before an XML Processing Instruction and your application won’t compile!
An XML tag can contain information in two ways, either by content or by attributes. Content is simply the text that exists between the node’s opening and closing tags. Attributes are value assignments inside the opening tag. Consider the XML in Example 4-7.
Example 4-7. XML with attribute information
<book title="Learning Flex 4" author1="Alaric Cole" author2="Elijah Robison"> <chapter title="Using Design Mode"/> <chapter title="Using Source Mode"/> </book>
In this example,
<book> is the root node, but
author2 are attributes of that book. This code also has two nested tags representing chapters, and each has a title attribute.
Compare the previous code to Example 4-8, which contains the same information using a different structure.
Example 4-8. XML with content information between the tags
<book> <title>Learning Flex 4</title> <author1>Alaric Cole</author1> <author2>Elijah Robison</author2> <chapter3> <title>Using Design Mode</title> </chapter3> <chapter4> <title>Using Source Mode</title> </chapter4> </book>
The second example is essentially the same as the first, but the second is more verbose. The first example uses attributes, and the second uses nested tags. So, attributes can be useful as a compact way to represent information, and more compact means more readable. Compare this code to the same example in MXML.
You’re probably used to seeing something like this:
Learning Flex 4"
But did you guess you could do the following?
Those two code snippets create the same product, but one uses an attribute to add the
text property, and the other uses a nested tag. We recommend using attributes in your MXML for the reasons stated earlier: compactness and readability.
There will be times, however, when you’ll need to use nested tags instead of attributes. This is because nested tags allow more complex content than a single line of text or a number. In other words, nested tags are preferable for adding data that can’t be represented as simple attributes. Consider the case of the
text property. If the text were a whole paragraph, it would look strange as an inline property.
Similarly, nested tags are essential when assigning complex data properties. For example, you might use an
ArrayCollection to supply data to a control, and some controls can display a long list of items. Example 4-9 shows a relevant example.
Example 4-9. An MXML ComboBox with a nested ArrayCollection
The same is true for complex components that may require an array of other component objects, such as the
columns property of a
DataGrid, which takes an array of
DataGridColumn components, each with its own properties. You can see an example of this by dragging a
DataGrid control to your application in Design mode, which gives you the MXML in Example 4-10.
Example 4-10. An MXML DataGrid with nested DataGridColumn components
Column 1" dataField="
Column 2" dataField="
Column 3" dataField="