Mihai has posted 2 posts at DZone. View Full User Profile

The Architecture of Flex and PHP Applications

06.01.2010
| 36569 views |
  • submit to reddit

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
Alert.show(event.errorID);
}

 

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.

 

Security

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.

AttachmentSize
fig1.jpg37.87 KB
fig2.jpg19.46 KB
fig3.jpg44.88 KB
fig4.jpg17.38 KB
fig5.jpg27.95 KB
fig6.jpg80.4 KB
Published at DZone with permission of its author, Mihai Corlan.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)