Application Development at AMFPHP

Oddly enough, in the vast expanses of the Internet, I have not found a single full-fledged manual (in any case, Russian) on developing applications for AMFPHP. About a year ago, this kind of article was very necessary for me, but due to the lack of such, I had to collect all the grains from different sources. I hope it will be useful to someone.

AMF

So what is AMF? Let's not reinvent the verbal bike and turn to wick for help:

AMF (Action Message Format) is a binary data exchange format used in applications written in Action Script. It is built on the basis of the Simple Object Access Protocol and is mainly used to exchange information between Adobe Flash and databases. Action Message Format is more economical in traffic compared to XML and allows you to transfer typed objects. Announced December 13, 2007
')
At the moment, AMF is the most current data transfer format between the flash application and the server part. AMF libraries exist for almost all server languages, but today I would like to focus on PHP.

AMFPHP vs. Zend amf

After you have chosen PHP as the server part of your application, you should decide which package to work with this format you will use in the future. At the moment there are two most relevant projects: AMFPHP and Zend AMF. There is no big difference between these two products, so it’s rather a matter of taste, but I chose AMFPHP for my projects because:

• It is lighter and more compact
• It is an independent project, not part of any framework.
• According to the test results, AMFPHP is at least 3 times faster than its competitor.
• I don't like Zend per se

Beginning of work

Since this is an AMPHP manual, and not AMF as a whole, I’ll focus on the server side directly. In addition, flash, for the most part, no matter what the beast is on the server - all requests are universal for AMF format, and hence a large number of relevant materials on the network.

Suppose that the root of our project is the root of the web server. In my manual I will denote it as / . The first thing you have to do is download the stable version of AMFPHP (at the time of this writing, version 1.9 is such) and unpack the archive in / amfphp. You can find it via this link.

Now you need to make a little adjustment. For this:

• In the /amfphp/globals.php file , in the $ servicesPath and $ voPath variables, specify the full path to the / amfphp / services and amfphp / services / Vo folders, respectively
• In the /amfphp/gateway.php file, we are looking for a call to the $ gateway-> setCharsetHandler () method; and set “none” as the first argument (the other two do not matter in this case)

Default gateway

Now you need to create a getvey to which all AMF requests from the client side will be sent. Of course, you can do with the standard /amfphp/gateway.php , but the application setup (be it class initialization, connection to the database, etc.) should be done before calling it

Create a file /gateway.php With something like this:

<? php

// ROOT directory
define ( 'ROOT' , '/ var / www / html /' ) ;

// timezone
date_default_timezone_set ( 'Europe / Moscow' ) ;

// load classes
require ROOT . 'loader.php' ;

// load amfphp
require_once ROOT . 'amfphp / gateway.php' ;

Now all the boot actions can be done in /loader.php .

Services and VO classes

All services are stored in the / amfphp / services folder. If your project implies MVC architecture (although in our case V is not very relevant), then the services themselves can act as controllers. These controller services can be inherited from any class (this will not affect the mapping), with the help of which you can organize access to the models and other methods and / or data of your application. AMF requests of the form ServiceName.MethodName will be sent to the MethodName () method of the ServiceName class, which should be described in the /amfphp/services/ServiceName.php file

VO ( Value Object ) classes are the classes available for mapping between the AS and the server parts of the application. All VO classes must be in the / amfphp / services / Vo folder. It is worth replacing that the file with the description of the class that came with the AMF request will be loaded automatically, whereas in order to create an object on the server side, the file will have to be included manually. But all these questions disappear when using the great __autoload () function:

<? php

function __autoload ( $ class )
{
if ( file_exists ( ROOT . 'amfphp / services / Vo /' . $ class . '.php' ) )
{
// VO
require ROOT . 'amfphp / services / Vo /' . $ class . '.php' ;
return true ;
}
else
{
// error
throw new Exception ( 'Class \' ' . $ class . ' \ 'could not be located!' ) ;
return false ;
}
}

Suppose we need to send the class UserDataVO to the client. To do this, create the file /amfphp/services/Vo/UserDataVO.php with the following content:

<? php

class UserDataVO
{
// Explict type
var $ _explicitType = 'UserDataVO' ;

// some user data here ...
}

And one more important note. If the name of the VO class on the client side contains dots, then amfphp converts from to slashes. This means that the AS class app.Vo.UserDataVO should be described in the /amfphp/services/Vo/app/Vo/UserDataVo.php file as follows:

<? php

class UserDataVO
{
// Explict type
var $ _explicitType = 'app.Vo.UserDataVO' ;

// some user data here ...
}

Please note that the explict type contains the full class name, while the name of the php class itself is only the last part of it.

That's all. I think this article is useful for developers who first encounter with AMF in general and AMFPHP in particular. Thanks for attention.