MXML Continued... And A Sample Application For You To Work With!

 

MXML Continued... And A Sample Application For You To Work With!

In our last installment, we briefly introduced the MXML language. We learned that all MXML tags are used as a sort of "short hand" representation of ActionScript code in Flex applications. This time, we continue to look at MXML and it's role as a helpful tool within the Flex programming environment.

All of the material in this article involving code, and indeed all code examples so far in the series, have been written using Flex Builder 3.0. It's worth noting that although we haven't yet devoted an entire installment to the use of Flex Builder, (we will very soon), those new to Flex and wishing to learn more should definitely head straight to the Adobe product downloads page and grab their free 60 day trial. Flex Builder is as good as it gets as far as I. D. E.'s are concerned, and a great way to learn programming is to start messing around with code to try to get things to happen. On that note, we've included a sample application for you to experiment with, but more on that later.

We already know that MXML refers to ActionScript code, but in what way does it do that? To better understand this concept, it helps to know a little about the kinds of situations in which you'd use MXML in Flex. In other words; what types of MXML "documents" you are likely to create.

The most common types of MXML documents that can be created for use in Flex applications are application documents and component documents. Every Flex application that uses MXML requires an application document, but not necessarily a special component document, as we'll soon see.

Component documents are handy though, as they can used for creating customized components as simple as a Button control, or for more complex tasks, like dividing an application into modules, which can go a long way into ensuring that an application will run quickly. The included sample application makes use of a component document to define a custom Button component. An important concept to grasp is that both application and component documents are extensions of classes and are in fact classes themselves.

Application and component documents have root tags that are named after their base classes. In the case of application documents, the root tag always extends the Application class. Component documents, on the other hand, have root tags named after whatever class the given component extends.

When you create a new project in Flex Builder, the code automatically generated is an application document, and it looks like this:

<?xml version="1.0" encoding="utf-8"?>

<mx:Application

xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">

</mx:Application>

Among other things, this code defines the application. The first line is what's known as an XML declaration. Technically, you can code an MXML or XML document without including this, but it's considered a best practice to include it, (and Flex Builder does this automatically for you). The declaration simply tells the parsers what version of XML encoding, as defined by the W3C, you're using.

The next line is the starting tag of the application. In addition to marking the beginning of the application, because it is the root tag, the default namespace for the document's classes is defined here as well. Earlier in the series, when we were discussing package declarations, we mentioned the importance of declaring them within a unique namespace in order to distinguish them from similarly named packages. Just like if you are in the room with more than one person named "Tom", for example, you'd address the person you wish to actually talk to by saying something more specific than "hey Tom"! The same goes for referencing objects within an application. So therefore, the code that reads:

<mx:Application

xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">

can be translated into English as: "Within this instance of the Application class, the XML namespace uses a tag called "mx", and has as a part of its identity, the phrase - 'http://www.adobe.com/2006/mxml', which is a unique name that is unlikely to be a part of any other namespace". The "layout='absolute'" declaration is what defines how the child objects of the application are to be laid out, meaning that their location depends upon a specific "x/y" coordinate. Other possibilities include "layout='horizontal'", which lays out child objects horizontally, and "layout='vertical'", which lays the child objects in a vertical orientation.

The point about the application tag referring to an instance of the Application class is an important one to understand in order to see how MXML tags work within an application. Remembering that tags refer to a class's objects will help to make sense of what we are looking at when we see MXML code.

The information that follows (<mx:Application), and comes before the (>) on that line are known as tag attributes. As we'll soon see, an MXML tag can hold information in attributes, as in the above example, or in content tags. A tag's attributes are anything that comes before the end of the opening tag, and a content tag is the code that is placed in its own separate tag, and then placed between the opening and closing tags. (<opening tag> <content> </content> </closing tag>) In most cases, the results are the same if you use attributes, or if you embed the content in nested tags. Consider that the following code:

<mx:Button label = "magic" />

means the same as this code:

<mx:Button>

<mx:label> "magic" </mx:label>

</mx:Button>

Both of these examples refer to an instance of the Button class' properties (label), they just do it differently. In the first example, the property is listed inline, whereas in the second, it is nested. The choice to code your MXML in the form of attributes or within nested tags may have to do with the complexity of the properties and methods you need to access within the tagged object. For example, I may do this:

<mx:Button label = "HI" />

But, if things got a bit more complex, I might do this::

<mx:VBox>

<mx:Button label="my button 1" />

<mx:Button label="my button 2" />

<mx:Button label="my button 3" />

</mx:VBox>

So, in a sense, just as MXML makes bringing ActionScript into your application much easier, having a choice between using tag attributes and using nested tags can also make things go smoother.

An important part of most application documents is completely ignored by the parser . We've discussed "comments" before as they apply to ActionScript, and just like other markup languages, MXML has them too. By typing (), just as in HTML and XML, the content within those tags will be ignored by the parser.

Another important tag to be familiar with is the <mx:Script> tag which is followed up by what's known as the "CDATA" section. When you see something like this:

<mx:Script>

<![CDATA[

]]>

</mx:Script>

what you are seeing is a place where you can put ActionScript code into your MXML application. The script tag let's the MXML parser not to treat it's contents as markup code. Content within the CDATA tags is interpreted by the ActionScript compiler instead.

Hopefully we've covered enough ground since the beginning of the series so those that are new to Flex can start to make sense of an actual application when viewing the source code. As mentioned earlier, we've included an example application in this post for you to work with. It's a calculator that doesn't work yet; it needs to have the logic programmed into it! It looks nice, and a few of the buttons do stuff to get you started, but you'll need to figure out how to use ActionScript and MXML to get it working properly. This is a great way for beginning programmers to gain an understanding of Flex beyond simply reading about it. To program this calculator you'll have to think about what it needs to do exactly, at every moment, and come up with a logical sequence of events. You should be able to get everything to work by manipulating some variables and functions in the event listener, but feel free to take any road you wish to make it work.

A few tips:

1- There is a custom component in this Flex project called "CalculatorButton", and it's in a small MXML document called "CalculatorButton.MXML". (note the correlations between the application document and the component document).

2- There are several "correct" ways to get this to work, and you can learn a lot from figuring out different versions of the same application.

3- I skipped the "M" buttons in my version because I never use them on real-world calculators anyway, although by all means, go nuts!

4- Once you can get it to add, subtract, whatever, you're close to being able to get it all to work!

5- You may have to create a sub-folder called "libs" in your project folder if Flex Builder doesn't create one for you, otherwise your program may not compile.

6- "Getting the calculator to work" implies actually getting it to do math correctly, not simply displaying something like "I'M A ROCKSTAR!" when you click any of the buttons, apparently.

7- Good luck!

 

The Sample Application

To get started with this example application using Flex Builder, click on the "download source" link and choose "save to disk". Make a note of where the zip file gets stored. Open up Flex Builder, and under "file" choose "import", and "Flex project". Make sure "archive file" is selected on the next screen and browse to the zip folder that holds the application. If everything is as it should be, you should be able to click on the "finish" button at the bottom. You should see the Flex project appear in Flex Builder's navigator window. Click on the project icon to expand the view into several folders. Click on the src folder, and then click on Calculator.MXML. This is the main application file. Notice the other MXML file - CalculatorButton.MXML. From here you can experiment with workspace views, namely "source mode", and "design mode". Enjoy!

In the next installment, I'll share the results of my attempt at making this calculator work. We'll get into using Flex Builder as it applies to this project, and we'll set the course for more discussions on using the tools of Flex.

View Source - Download Source

 

Glossary of Terms

XML - Extensible Markup Language. A markup language (or perhaps, pseudo-language), in which you create custom tags to define the way data is carried.

MXML- An extensible markup language created by Adobe for use within the Flex framework. Much speculation surrounds the meaning of the "M", or perhaps "MX" in the name, as no official acronym has been announced.

CDATA- The section of a document which the parser doesn't interpret as XML or MXML, so that a programmer may put ActionScript code code in.

application document- The main MXML document in a Flex application, that extends the Application class.

component document- An MXML document that is used to create custom components.

module- A section of code within an application that is set apart to facilitate an applications run time efficiency.

markup- elements of language that are used to determine the layout of data.

tag- In markup languages, tags such as (<,/>) are used to define the beginning and end of important content.

attributes- In MXML, a tag represents an object, and attributes are the properties/methods of an object listed before the end of the opening tag.

nested tags (content)- In MXML, a tag represents an object, and nested tags refer to the properties/methods that are listed between the opening and closing tags of the object.

XML declaration- A technically unnecessary, albeit proper declaration to include in an XML document that announces the particular encoding that will be used as set by the W3C.