With the exception of the FDS2 deployment that was discussed earlier, the deployment of a Flex 2 application is very similar to Flash deployment. Flex Builder, by default, sets up a deployment directory that is used when debugging, although you can customize your deployment as you see fit. The only thing to keep in mind when customizing a deployment is that you must keep your pathing correct - meaning that, if you nest your XML files in an /xml folder for run-time parsing, you must ensure that your Flex application is pointing to that /xml folder. This applies to any external, nonembedded assets.

The following table shows a basic customized deployment directory structure.

Open table as spreadsheet

Deployment with Flex Builder 2

If you are using Flex Builder 2 or the Flex Builder plugin for Eclipse, as mentioned before, both create a deployment directory for you. Located in your application project’s root directory is a /bin directory. This is where all of the wrappers are kept. The following table describes this structure.

Open table as spreadsheet

As you can see, by default, Flex Builder’s deployment isn’t very organized, but it works well for testing. However, if you’re going to use your own wrappers and directory structure with Flex Builder, keep in mind that you have to tell Flex Builder to not build out the wrappers by default, and redirect Flex Builder’s RUN and DEBUG commands to your custom wrappers.

Figure 18-9 illustrates how to disable HTML wrapper generation within the properties of your application. To do so, uncheck “Generate HTML wrapper file.”

How you compile your Flex application will rely greatly on which installation method you chose for the Flex 2 SDK. If you chose to install Flex Builder 2 or the Flex 2 Eclipse plugin, compiling is as simple as clicking the Run button. Other installations (such as the Flex 2 SDK) will require that you use mxmlc.exe to compile your application. This section discusses the basics of compiling.

Each example uses a very simple Flex test application called CompileTest.mxml. Here is how the file appears:

<?xml version="1.0" encoding="utf-8">
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
<mx:Text text="EVERYTHING WORKS" size="30" />
</mx:Applcation>

If you compile successfully, the resulting SWF should look

Compiling with mxmlc.exe

If you’re using the Flex 2 SDK without the Eclipse plugin or Flex Builder 2, you must use the mxmlc.exe compiler. The mxmlc.exe compiler is a free compiler by Adobe that compiles MXML and ActionScript 3 files. Therefore, you can create both applications using the Flex Framework, as well as Flash modules that are independent of the Flex Framework. The difficulty level in using the mxmlc.exe method of compiling ranges from extremely easy to moderately complicated, depending upon the flexibility you would like to have during the compile.

Drag-and-Drop Compiling with mxmlc.exe

The easiest method to compile an application is to drag your application MXML file to the mxmlc executable. Figure 18-6 illustrates dragging an MXML file. In this case, it’s the CompileTest.mxml file mentioned at the beginning of this section, and you dragged it onto mxmlc.exe icon located in {Flex 2 SDK Root}/bin/. If you’re using a Windows operating system, you will see that an instance of the command shell pops up for a second during the compiling. If the compiler finishes successfully, your compiled SWF will be located in the same directory as your MXML file.

Command-line Compiling with mxmlc.exe

If you’re looking for flexibility and options, using the command line to compile your application is the way to go. This example compiles the CompileTest.mxml file that was mentioned at the beginning of this section. If things go well and it compiles, your SWF should look like Figure 18-5. This example is Windows-specific, but you can compile from using the Terminal in Apple OS X.

In Windows, open up the command line by clicking Start Run. When Run opens, type cmd in the Open field to open the command shell. At this point, it’s good to get acclimated to the options that mxmlc.exe has available for you to use.

Locate the mxmlc.exe file on your hard drive. For this example, mxmlc.exe is located in C:\Flex\bin\mxmlc.exe, although it may not be located in this location on your computer. Now that you know where on your computer the mxmlc.exe is installed, using the command shell, navigate to your project. This example uses the CompileTest.mxml project example from the previous section. Once you’ve located your project, type the following at the command prompt:

C:\WROX_FLEX\COMPILE_TEST> C:\Flex\bin\mxmlc.exe CompileTest.mxml

At this point, the mxmlc.exe will load your flex-config.xml file, and it will compile your SWF. If you are following the example, the end SWF should look like Figure 18-5.

Many more options are available to you when compiling. If you are interested in these options, Chapter 19 discusses command-line compiling and debugging in more depth.

Additionally, as you develop your project and it becomes increasingly more complicated, it is recommended that you use a build tool to help automate the compiling process. Although there are many different build tools out there, one of the more popular is Apache Ant. When you tell Ant to compile, it looks for a build.xml file that contains instructions for how to compile your Flex application. For more information on Apache Ant, please refer to http://ant.apache.org. If you are interested in other build tools aside from Apache Ant, Wikipedia is a terrific place to start (http://en.wikipedia.org/wiki/Build_tool).

Compiling when Using Flex Builder 2, or the Flex Builder 2 Plugin

Compiling using Flex Builder and Eclipse with the Flex Builder plugin is the simplest way to compile your application. After you have created your project and have created at least one MXML application, you can click the Run icon, or the Debug icon if you are choosing to debug your application. Both icons are highlighted in Figure 18-7.

Earlier chapters have discussed what Data Services are (Chapter 3) and how to configure and manipulate data using the Flex Data Services 2 (Chapter 11). This section discusses the building and deployment concerns when dealing with Flex 2 Data Services (FDS2). This section requires that you have FDS2 installed on your development machine.

Developing with FDS2 is a lot like developing with the Flex 2 SDK. In both environments, you will be creating applications using ActionScript 3 and MXML, and your end product will be a single SWF that is downloaded to the end user’s machine. However, there are many important differences between the two.

The main, critical difference between the two is that FDS2 gives you the option of either precompiling locally in the IDE and uploading a single SWF to a hosting server that will interact with the FDS2 services, or uploading your uncompiled ActionScript and MXML source to the J2EE-compatible server, and allowing FDS2 to compile your application SWF on the fly when the first HTTP request is made to the application’s root MXML file.

Figure 18-2 illustrates the FDS2 deployment environment, which is much like that of a Flex 2 SDK deployment. Compare Figures 18-1 and 18-2. In both setups the developer uploads a compiled SWF to the deployment server, which is, in turn, downloaded by the end user when it is requested over HTTP. However, Figure 18-2 uses FDS2, which allows the SWF to utilize the FDS2 messaging architecture. Once the users download the SWF onto their machines, they are able to asynchronously communicate directly with the server running FDS2 through the server’s J2EE application using ActionScript Message Format (AMF)/HTTP.

illustrates a deployment structure of an FDS2 application using server-side compiling. In this configuration, the developer uploads the Flex 2 application source directly to a server running a J2EE application and FDS2. When the first HTTP request is sent to the server, FDS2, through your J2EE application, compiles the application source to an SWF using the mxmlc.exe compiler. After the SWF is compiled, the end users download it to their machines. When the source has been modified, FDS2 will notify the J2EE application to recompile the SWF on the server. Otherwise, it is cached on the server for future requests. Once the end users have received the SWF, like the configuration in Figure 18-2, they are able to asynchronously communicate directly with the server using AMF/HTTP.

The FDS2 application structure is shown in Figure 18-4. Although it is discussed in more detail in the next section, it is helpful to understand that, in this context, your J2EE server (this example uses JRun4) looks for the mxmlc.exe in a specified location (/bin) and compiles the SWF to the deployment directory (/servers/default/flex/).

Application development and deployment structure aside, other differences between FDS2 and the Flex 2 SDK are, for the majority, configuration- and security-related. If your application relies on utilizing the FDS2 messaging architecture and compiling features, you will want to set aside more time for planning and configuration. Server-side application configurations tend to be more complex and will slow down development if they are not properly considered ahead of time. Likewise, because you are working with a J2EE server, you will want to ensure that, along with securing your Flex application, you take the appropriate steps to secure the J2EE application, as well as the data being sent and received through AMF.