amfphp and value-object

The Value-Object mapping of AMF-PHP has got some strict ahearance, with the folder, the PHP VO classes are put in. It was a good experience for me as I was porting my weborbPHP into AMFPHP and just over look the folder restriction issue in AMFPHP. Ok, the buttom line is all the PHP VO classes must be put inside “service/vo/” folder on the AMFPHP installation.This will result in sending VO objects from PHP to Flash or else on the Flash side one will get only Object not a value object. So the basics are 4 steps are,

1. Add a “RemoteClass” meta tag on Flash VO object
package com.saumya.openmanage.model.vo
public class UserProfileVO
2. Add “$_explicitType” property on PHP side VO
class Profile{
var $_explicitType=”com.saumya.openmanage.model.vo.UserProfileVO”;
public function __construct(){}
3. Register the VO class on the main application class or the program entry point class before you use any value objects“com.saumya.openmanage.model.vo.UserProfileVO”, UserProfileVO);
4. Put all the PHP value object classes in a subfolder of “services” folder named “vo” in an AMFPHP installation(“service/vo/”).

happy flashing :)


5 thoughts on “amfphp and value-object

  1. No, you don’t have to put your VOs within the service/vo folder, that’s just where amfphp looks by default. There is a variable named $voPath in globals.php which you can set to tell amfphp where to look for the classes. There’s more info at , it’s targeted towards flex but the only difference is that with Flex you don’t have to manually do the registerClassAlias() stuff because RemoteObject handles that for you.

  2. Hey Rich,
    This is true, but then the problem here is there will be only one folder at all the times which will contain the VOs. It cannot be project specific settings for VOs. If we change the path to some other path, then all the VOs in all my AMFPHP applications must go inside the newly named path. My point here is we always have a particular folder containing VOs.So why not just use the default one?

  3. Can’t you just create separate instances of the amfphp folder structure if you want to separate by project and update the services-config file accordingly? Can you think of any disadvantage of this?

  4. you sure can have project-specific VO directories. The globals.php file is loaded before anything else in amfphp, so you can do whatever configuration you need to in there, like setting the vo directory depending on the project. You can actually set i[ up so that you have one main installation of amfphp, and have separate services/globals.php for each different project.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s