The Architecture of Flex and PHP Applications

DZone 's Guide to

The Architecture of Flex and PHP Applications

· Web Dev Zone ·
Free Resource

I've been working with web related technologies since the late '90s, and my first server side technology was PHP. Later on, I did ColdFusion and Java development, but I always considered myself a PHP developer. When AJAX came along, I started working with frameworks like Prototype and script.aculo.us, and I began building my own frameworks.

At the end of 2006, I had my first taste of Flex development. It was kind of a crash course, because I had about 4-6 weeks to create a demo application for the upcoming version of FDS (Flex Data Services, now called LiveCycle Data Services). Although I was new to Flex and FDS, the project went well, and I really enjoyed the development and learning process.

However, enjoyable as it was, it was different. I mean that when I did ColdFusion or Java web development, it didn't feel different compared to PHP; it was more a question of finding the right APIs and getting acclimated with the specifics of the language. Later on, when I started doing AJAX on top of DHTML, it wasn't that different either. You still create most of the website using the same techniques with the help of a server-side language, and you just throw in some spices here and there (in this case, some AJAX widgets).

When I did my first web project using Flex, boy oh boy, it was quite a switch! The clean separation between the client and the server, (the business logic on the client side in addition to business logic on the server side), client-side technology that is compiled instead of interpreted, two languages on the client, all these required a different mind-set from traditional web development.

And this is my reason for writing this article. I want to share with you some of the things that are specific to Flex in relation to PHP. And I want to show you how common tasks for building HTML/PHP applications are done with Flex and PHP.


Client/server architecture

If you want to categorize Flex applications, you can say that Flex applications follow SOA architecture model, where Flex is used to create the client and you connect the client to data using services.

Let's go back to browsers and how web applications are delivered. When the browser makes a request, the server uses a combination of static content (HTML/CSS/JS code) and scripts (these scripts may query a database or call other scripts, but in the end they output HTML/CSS/JS) to prepare a page. This page gets loaded and rendered by the browser. A key element here is that, usually this page (or response) has the presentation markup and the data baked into the same message.

When a new state of the application is to be presented, the browser makes a new request and the server prepares the page. The client "just" renders the data.

Flex applications works differently. The server sends the compiled Flex application (the SWF file) that runs inside the browser using the Flash Player plug-in. Usually, this SWF file holds only the client-side business logic. If data are need (from a database for example) the Flex application makes a request for those data. The server sends only the data (this can be in XML, JSON, AMF3 format), and the client knows how to represent this data visually. What we have here is a service oriented architecture: The Flex application is the client―a client that can consume data services from the server. The application can change state without refreshing the page or reloading the SWF file in the browser. The application is a client that can do more than "just" render data. Thus using Flex and Flash Player it is possible to create almost anything that makes sense to deploy on the web, from games to applications, to widgets that are integrated within "classic" web applications, and more (see Figure 1).

Figure 1. Flex and PHP architecture


Connecting Flex clients to PHP back-ends

As a PHP developer, you have a very direct way to read data, parse them, and display them on the screen. Connecting to a MySQL database is one of the first things any PHP developer learns.

What about Flex? I have to disappoint you, because you don't have direct access to data stored in a database. Why is there no direct way of reading data from a database? Because of the old saying "You should never trust the client!" Suppose the client is a Flex component that knows how to connect to the MySQL server. How do you store the credentials so that it wouldn't be easy to steal them and have the database compromised? Set a different user/password for each user and give them this information? This is just one of the reasons why it is not a good idea to have a client technology that can connect directly to a database server, without using an application server in the middle.

Basically, in Flex applications you rely on server-side scripts to manage the databases. Flex offers you a way to call the server pages and get back the answer in Flex. Basically, you can connect a Flex client to a PHP back-end in two ways: over HTTP or using sockets.

Over HTTP, there are four different ways to connect to a server data source: REST style services, web services (WSDL/SOAP), remoting (or RPC), and XML-RPC (see Figure 2).


Figure 2. Flex – PHP HTTP based communication

You can use the HTTPService class to use REST style services. You can send POST variables when you do a request, and the response can be XML, JSON (there is a third-party library for parsing JSON), or custom formatting.

If you have web services on the server (SOAP/WSDL), you can use the WebService class.

But the most interesting method is remoting (using the RemoteObject class). There are three reasons why I think it is the coolest method. First, using remoting you can leverage any PHP class you have on your server by calling any public method. Basically, from the Flex side you use an instance of RemoteObject as if it were the remote PHP class. Second, you can map the data model from the PHP side to an ActionScript data model, and have the conversion done automatically. This is extremely important, because when you use typed objects, you get the benefits of compile-time error checks and code completion. This means code that is easier to read and less prone to bugs. And third, the messaging format for this method, AMF3 (Action Message Format) is a binary format, which can be much faster and smaller compared to SOAP/XML/JSON, especially for big sets of data. The format itself is open, and anyone can read the white papers and implement programs that use it.

AMF3 is faster because it encodes data. For example, if the same string is repeated in a data set, it is encoded one time, and all other occurrences of the string are references. If a number is smaller than four bits, only the minimum number of bytes required are used (see Figure 3).


Figure 3. Remoting or RPC


Remoting is natively supported by Flex, however on the server side the story is not the same. PHP doesn't support remoting and AMF3 natively. This is why you need a server side library to enable remoting for a PHP web server. There are four available libraries, all are free, and I wrote tutorials about how to use each of them: Zend AMF, AMFPHP, WebORB for PHP, and SabreAMF. And here you can read a post that compares them.

The last method used by people for integrating Flex with PHP is the light-weight web services XML-RPC. This is for example what Drupal offers out-of-the-box if you want to create modules that uses Flex or AJAX. In order to use XML-RPC you need a library for both the client (xmlrpcflash) and the server (phpxmlrpc).

If you want to connect using your own protocol built on top of sockets, you can use sockets communication. You can create a socket server on the PHP side, and from the client you can connect to this server and exchange data. Just a reminder―when creating Flex applications that target the desktop (running on Adobe AIR and not in the browser) you can create socket servers on the client side too. Here is a good article about working with sockets with Flex and PHP.

Asynchronous nature of Flex

The asynchronous nature of Flex is something rather different from anything in PHP. It is important to understand this, stop fighting it, and go with the flow.

What does it mean that Flex is asynchronous? Suppose you create a Flex application, and after the application is loaded in the browser, the user can choose to load pictures from another site. You might use a URLLoader class for this task. When you execute the load() method, on the next line of code you won't have the data. The script doesn't pause after the load() call waiting for the data to be loaded. Instead the execution of the script is resumed. As a programmer you deal with this asynchronous nature using the built-in AS3 events system. If you're familiar with AJAX programming, this is similar to what you do when you make an AJAX call: you provide a callback function, and when the data arrives the callback function is called and you can access the loaded data.

Suppose you have a Flex application that loads a picture from a web server. In order to deal with the asynchronousity, you would add an event listener for the result event. This is the function that will be called once the data is loaded. Here is an example of how the code might look:

function loadPic():void {
var loader:URLLoader = new URLLoader();
loader.dataFormat = URLLoaderDataFormat.BINARY;
//adding the event handlers or listeners
loader.addEventListener(EventComplete, picLoaded);
loader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, picError);
//starting the loading
loader.load(new URLRequest("http://some_url"));
//event handler for the result event
function picLoaded(event:Event):void {
//get the data from the loader object
//use the target property to get the loader object
(event.target as URLLoader).data;
//event handler for the error event
function picError(event:IOErrorEvent):void {
//displays the error id in a pop-up windonw


I can summarize it like this: Don't call us, we'll call you!

As I said, AS3 has a built-in event system. The top class of all events is Event. All objects that work asynchronously have an addEventListner() method, and the first two arguments are the event type and the name of the function to be called when the event occurs. You might think that only objects that deal with retrieving remote data are subject to this event model. Actually that is not the case; all components or objects that are visual also have events. For example, every Flex application has a creationComplete event. This event is triggered once all the required components from the application are processed and drawn on the screen.

Although you might feel that such code is not as straightforward as PHP, there is a good reason for having asynchronous calls scattered around in Flex (and Flash Player): Flex is a client-side technology. If all calls were synchronous, the user interface of the application would stop being responsive for any call that involved loading data, for example. And users hate unresponsive user interfaces.

You can cancel some events and even change the default behavior. I'll let you explore these details on your own if you need to; for now you should have a fairly good idea of what events and event listeners are all about.



First of all let me tell you that you can communicate from Flex over HTPP or HTTPS. It depends on your need.

Second, when it comes to user authentication you can use basically the same workflow you use in HTML/PHP apps. For example suppose you authenticate the user from the client (could be an HTML form or could be a form from the Flex application itself). Back on the server, you validate the credentials and if correct you set some flags in session. All the calls you make from the Flex client to PHP scripts (using REST services, web services, remoting or XML-RPC) will append the session id to the request, and as a result the PHP will be executed with the same session information. And based on the session information you can check if the user has the rights to do what the operation is trying to do.

When it comes to code execution loaded after the application was initialized (for example your Flex application loads some widgets from other servers), Flash Player offer sandboxes as a way to ensure that foreign code (and potentially dangerous from the point of view of the security) is not accessing the variables from the main Flex application. This is done by default. For example if you have a Flex application that loads a weather widget from another domain, you don't want the weather widget code to find what is the user name or his bank account is (suppose that the info is part of the Flex app).

If you trust the code you loaded (although this is a security risk) you can "import" instead of loading, and the widget code from the above example could execute in the same application domain as the Flex application code.

If you keep the loaded code in a separate domain (you don't "import" the code), you can communicate from one domain to another using Local Connection. You can read more about these here. HP created a free application called SWFScan that scans Flash applications for a number of vulnerabilities. This is a good way to ensure that you don't make mistakes.


Debugging Flex and PHP applications

The key element to keep in mind is: now, you have a client that is separated from the server, and problems may be on the client, on the server, or at the network level.

You can debug Flex code using the debugger from the Flex SDK, or the debugger from Flash Builder 4. If you choose a combined setup of Flash Builder 4 and Zend Studio, you can debug the PHP and Flex code from the same project very easily. Here is a tutorial on Zend Studio and Flex Builder debugging.

We added two new views to Flash Builder 4 that help you to debug the code: Network Monitor and Test Operation views. If don't see these views you can add them from Window > Other Views… and look up at the views of the Flash Builder node (Network Monitor is available only in Flash Builder Premium).

Using Network Monitor view you can see all the communication that goes between the Flex client and the server. You can see both the raw data and the objects. If you want to use it, the first thing you have to do is to enable this feature: click on the Enable Monitor icon (see Figure 4).


Figure 4. Enabling Network Monitor

After this, just run the application (you don’t have to do it in debug mode). As you use the application and data are exchanged with the server, you should see the requests, how long it took and data were send/received (see Figure 5).


Figure 5. Using Network Monitor


Test Operation view, as the name implies, let’s you to test the available operations. Select Test Operation view and choose getData() operation and click Test. You should see the four VOAuthor objects (see Figure 6). If the operation expects arguments, then this view lets you define the arguments values.


Figure 6. Using Test Operation view


Where to go next

If you want to learn more about Flex and how you can integrate Flex apps with PHP back-ends, you can have a look at my blog (in addition to a lot of tutorials, there is an introduction to Flex for PHP developers). Another great resource is Adobe Developer Connection where you can find a section dedicated to Flex and PHP. If you learn better by listening, Adobe TV has a lot of videos or screencasts.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}