Here’s the status:
Cake implementation of AMFPHP via the plugin cpamf appears to be lacking some particular documentation regarding “accepting” flash objects in calls.
i.e.
Flash -> PHP object conversion.
Sure you can send back flash objects no problem, and there are plenty of documented places that tell you how to send flash objects back from PHP using class mapping and there was even some information on the reverse using AMFPHP on how to map VO’s from Flex to PHP using AMFPHP, but what seemed to be lacking was some particular documentation on how to get CPAMF, cake’s own brand of AMFPHP working with Flex VO to PHP. Begin investigation:
I am indeed hoping that I can get my controllers to accept objects instead of parameters or arrays. Allowing the flash app to pass through an object instead of having to decide what parameters or format it should be returning each time.
e.g.
Controller | Method | Parameter
TestController->test(StandardVO $vo)
As cake does; it likes to have controllers and models for everything it does. Aren’t you a nice cake! *grumble*
So it’s written it’s own CakeGateway.php class to extend the PHPAMF Gateway class, overriding action calls for the gateway. Aside from overriding them all and not calling the parent::registerActionChain() that seems to be fine.
A little hunt through the documentation/notes and general settings in globals.php seems to indicate that you can set the directory for controllers and vo classes. Great I think; changing these values should resolve my problem. If only!
The CakeGateway class appears to initialise the gateway with it’s own set of parameters for the controllers, sensibly (for a change) reading cake’s default controllers folder. Thus, all appears to be working within the /cpamf/browser , but still without the ability to pass objects, DOH!
The voPath mapping that appears to be set from the original globals file points to “services/vo”, i’m assuming this is supposed to indicate the current directory is the base and the services/vo folder is the one containing the vo’s. Thus, following some logical thinking I begin to stuck some classes in various folders that cake might just be reading.
In goes a StandardVo class, in the models/ directory and also inside the plugins/cpamf/vendors/amfphp/services/vo directory, try again. Nope still not recognising my object.
Ok, I know Cake’s naming convention is totally crap, lets try naming the file standard_vo.php instead of StandardVo.php . Still nothing, despite being implemented in both directories.
A few hours later, and after a fair amount of digging around in AMFPHP I came across what looked like some form of include()’ing. Having managed to stop the flash from doing it’s thing an instead die()’ing in certain places, I realised that this part here was responsible for loading in the PHP class to map to (lines 351-396 of /plugins/cpamf/vendors/amfphp/core/amf/io/AMFBaseDeserializer.php). Stepping through the logic I saw it: “$mappedClass = str_replace(’.', ‘/’, $typeIdentifier);”
The mapClass() function was doing the magic; interpreting the type of the flash object (which seemed to resolve to a full package name) into an include. AH HAH! It was also resolving it relative to the customMappingsPath which we saw earlier was set in CakeGateway class (cake_gateway.php).
So it would seem that AMFPHP was expecting to see a full package naming convention for all the Flash Objects it was going to receive.
I headed back to the CakeGateway class and amended the setCllassMappingPath() to
// This is the path to the Vo models!
$gateway->setClassMappingsPath( MODELS . 'vo' );
I then created a “vo” directory inside the cake models directory, and further proceeded to mimic the flash namespace package path.
models/vo/com/test/StandardVo.php , et VOILA! Problem resolved; cpamf now knows which object it is receiving and fills it with the data received from the flash object.
Now back to pulling out some hair over other issues.