I've been sending ArrayCollections from php to Flex for a while, it's pretty simple and info for doing that can be found at Wade Arnold's blog here. The issue going the other direction is that Flex only sends the AC's underlying source array when serializing it for amf. So when amfphp unpacks the data, you're dealing with a normal array.

Obviously, the first thing you'll need is your ArrayCollection class to use (I use the version that extends ArrayObject at the link above), and make sure it is in your include path.

The first tweak to amfphp is to the method AMFBaseDeserializer->mapClass(). In that method, right after the checks looking for CommandMessage and RemotingMessage types, I added a similar check for ArrayCollection:

Next change is to the AMFDeserializer->readAmf3Object() method. Near the middle of the method, around line 570, there is a check for ArrayCollection, and if found it will call the readAmf3Data() method. I changed it to pass in a value of "true" to the method, you'll see why in a sec:

Now just two small tweaks to the readAmf3Data() method. I changed the method signature to add an $isArrayCollection parameter, which just gets forwarded on when calling readAmf3Array. Here's the whole method:

Now just another two small tweaks to the readAmf3Array method. As with the readAmf3Data() method, we add the $isArrayCollection parameter. Within the body of the method, I just check if that param is true when creating the $hashtable variable, and if it is, use an ArrayCollection instead of a regular array:

That's it. Now I can send the an AC to the server, serialize it, unserialize it and send it back to Flex with no issues. The one thing that may an issue is if one of the items within an AC is also another AC...haven't checked out if that works yet.

I am loving the new trend I'm seeing in a lot of the frameworks (both client- and server-side) I've been checking out lately. What I'm seeing is a move away from the monolithic, "do it my way or suffer trying to work around it" approach, towards more architectures that provide a more generalized, "less is more" approach, even to the point that some of the functionality and/or features of the "do-it-all" frameworks are being broken out into smaller, specialized bits that allow the developer to pick and choose between whichever approach best suits their style.

To me, the main benefit of the new trend is readily apparent: just as different individuals would write the same story different ways, the same goes for writing code. For one framework to dictate too much influence over too many aspects of an application, or even worse to make it difficult to extend or adapt to suit your needs, provides too much lock-in and and can hinder more than it's trying to help.

On the flash/flex side, frameworks like RobotLegs , Cairngorm 3, Gaia, and even libraries like CasaLib provide example of this (ok, Gaia probably goes a little further as far as initial structure, but once you start developing it stays out of your way). On the backend, for php you have things such as Konstrukt, a "URI-to-controller-mapping" (i.e., REST) framework which handles "routing based on logic rather than rules", and the Outlet and phpDataMapper ORM frameworks.

One thing about the above mentioned frameworks is that most, if not all, can be used in conjunction with each other (like so). If you don't like the way one part does it's job, you can more than likey swap out that part with a similar one without affecting the other parts of an application, provided you we good with encapsulation and keeping things pretty cleanly separated. This is not an insignificant side effect of the "less-is-more" approach, it's the central theme. It's having it your way.

I did some searching at first and saw someone saying that it was because the date.timezone setting for php was not set. So I added date.timezone=UTC to php.ini, and changed the PHP_COMMAND in the phing script to include the ini file, since running php from the command line does not automatically include it:
PHP_COMMAND="/Applications/MAMP/bin/php5/bin/php -c /Applications/MAMP/conf/php5/php.ini"

None of that worked, however, and after digging around a bit more I found there is a new undocumented attribute you can use in your schema.xml file called defaultExpr, which will insert the result of the expression directly into the database. So I just set defaultExpr="now()" and everything was good to go.

Turning that into a function we can specify if we want to increment or decrement the value pretty easily. You can also provide a starting point for the adjustment (so if you delete the item with displayIndex=15, you only want to decrement the displayIndexes greater than 15 by 1) and specify a different value for the WHERE clause:

There's a lot more you can do with it but it's been a pretty good starting point.

One of the issues I see a lot of with people using AMFPHP is how to properly map VO classes between Flex and php. It used to stress me out too, until I realized how easy it really is.

First thing: Don't worry about the package paths in the RemoteClass metadata tag and $_explicitType variables in your php classes. You don't need them.

Second thing: Just use the name of the class you are mapping in for the values RemoteClass("alias="") and $_explicitType="". For example, if you wanted to map a value object named 'Book' between flex and php, just use:

and

Like i already mentioned, you don't need the package names. The reasons behind this are:

• When sending from php to Flex, Flex will match the $_explicitType variable to the Remote class alias. It's just an id to match...it doesn't even have to be the class name...it can be jibberrish, as long as both strings match. (This won't work the other way though...see next item)
• When sending from Flex to php, AMFPHP will try to load the class with the name specified by the RemoteObject alias value. It simply looks in a specified directory to try and load the class...if it can't find it it's parsed as an array.

So, how does AMFPHP know where to look for the vo classes? Easy...you tell it exactly which directory to look in by setting the $voPath variable in globals.php. I usually do something along the lines of :

Here's a more flushed out code sample:

Say for example the Book.php class file is sitting on the server at webroot/php/classes/vos/Book.php. In order to tell AMFPHP where to look for the Book.php file, you open up globals.php in your AMFPHP installation, and set the $voPath variable to point to the 'vos' folder:

Now when you send a Book object from Flex to php, AMFPHP will look in the $voPath (which we just set to the 'vos' folder) for the Book.php file.

Note that the $voPath variable is the starting point of where AMFPHP will start to look. If you specify a full package path for the RemoteClass alias, such as:

then all the dots in the string are converted to slashes, and the full path is used. To continue with the example above, we have already set $voPath to point to the 'vos' folder, and the RemoteClass alias has been set to "com.website.vos.Book". AMFPHP converts the alias to "com/website/vos/Book" and will attempt to locate the file $voPath/com/website/vos/Book.php. In addition, if you're mapping this object from php back top Flex, remember the $_explicitType variable still must match the string for the RemoteClass alias, so you'd need to set that to:

As far as I can tell, this extension was left for dead a while ago but revitalized over the last year or so and is now rockin pretty hard. The developer is pretty responsive on the Imagick board at the ImageMagick forums as well, and he's got lots of nice code tidbits on his own blog.

There is also the MagickWand For PHP extension, but I found the syntax pretty odd to deal with, it probably relates more to the way GD works than the OO style of Imagick.

Then I went out and installed PDT to set up a PHP perspective within FB.