AMFPHP has had a long run at being the preeminent choice for connecting the Flash Player to PHP. It’s design goal of being quick to install and implement, low foot print, convention over configuration, and not being a framework are what has made it great for beginner to intermediate users. Moving forward AMFPHP will exist to meet these exact same demands. However there will be one major change the core of AMFPHP will be built from the Zend Framework AMF library which is being maintained be myself and the rest of the Zend Framework community. AMFPHP will have an additional code base that continues to make it simple for beginner to intermediate developers to start working. That is really the only difference in functionality.
Let’s face it if you were trying to use AMFPHP in an enterprise capacity it did not meet your needs. Development has stagnated due to antiquated code that was based on PHP4. It made it hard for everybody to try and make any changes or additions. When Adobe contacted me about adding the AMF protocol to the Zend Framework I was excited as I had already started the difficult process of scraping the entire code base of AMFPHP and starting over.
The goal of the core AMF functionality that will be used between the two branches will have the following goals.
Implement as much of the AMF protocol as possible in PHP
The design goals of the Zend Framework implementation of the AMF specification are quite different than AMFPHP as it is designed to be:
A tool that easily allows Flex and Flash developers to leverage the Zend Framework.
Highly Customizable (already frustrating to some)
Portable to be added to other Frameworks.
Moving forward AMFPHP will continue to support it’s driving goals of being quick to install and configure and support the large existing install base.
An AMFPHP 2.0 release is dependent on these remaining additions:
Service browser support
Resource set for database results.
AMFEXT support will not initial be support due to bugs that I need to fix in the extension.
If you believe that I am fragmenting the AMF for php code base then I did not explain the scenario. We are basically wrapping the same core with two different sets of classes for really two different types of end users. AMFPHP will be a fantastic fit for beginner to intermediate developers and when you need the horse power of a framework check out what I feel is the best one on the market Zend Framework.
In summery:
Need your clients IP or some database information into Flash/Flex in the next 15 minutes; AMFPHP is your friend.
If you’re going to change the world with an application that is enterprise ready and can leverage the wealth of code in a robust framework then check out Zend Framework. It may be a little more work at first but in the end you will be saying wow that is nice!
ALSO: There is no such thing is ZendAMF. I have seen this on some blog posts. There is the Zend Framework with the amf protocol server implementation using the package Zend_Amf and the class Zend_Amf_Server.
Zend, AMFPHP, SWX and I hope other project can leverage a new services browser that I started writting today in Flex builder 4. This is a two part project for me as I had never gotten into the AMFPHP service browser code or built anything with gumbo nor does Zend Amf have a discovery services. I am basing the code off of SWX Explorer. Aral did a great job! My hope is to get at least all the functionality back into this project and then place it on a new Universal Remoting project at GitHub for other projects to fork it with there logos and defaults.
Type Cast objects coming back in AMF are mx.utils::ObjectProxy and are capable of becoming the object type that you specified. However we don’t want to JUST ASSume that you are getting the correct object type back. It takes a small amount of work. In order to change the ObjectProxy into the proper data type.I recommend that you wrap your result into a try catch before you just assume that you have received the correct data.
private function onResult(event:ResultEvent):void{
try {
var myContact:ContactVO = event.result as ContactVO;
trace('name' +myContact.firstname);
}
catch(error: Error) {
trace('onResult error: ' + error.message);
}
}
Yes you could just Jam the type into a value.
var myContact:ContactVo = ContactVO(event.result);
But if something didn’t work out on the server and you get a successful result your application just crashed because you have a type correlation exception.
if you’re not going to null check the return from var and save the CPU cycle for the as().. thanks Ivan!
Joel Caspers a new T8DESIGN stud also says: Also, you can remove the need for try-catch statement entirely by using the is operator in an if statement – in my experience try catch statements are processor costly and I’ve always been instructed to stay away from them, as well as you could be catching an error that you are not intending to catch (something other than the cast error inside your try statement).
If (event.result is ContactVO) {
//it is what you think it is
Var myContact:ContactVO = ContactVO(event.result);
} else {
//the result is not what you think it is so spit out the type in the console
Trace(getQualifiedClassName(event.result));
}
The reason that AMFPHP just returned generic objects rather than mixed array is because it was primarly based off of AS2 which did not have mixed arrays only generic objects. Now that we have AS3 and actually able to re-write the parser we are going to return mixed arrays when that is the real data type for Amf3. This is not a bug it’s more that the bug was actually fixed.
So if you really want to return a generic array when you have a mixed array in php you can just cast the return and it will work like AMFPHP did.
public function returnData()
{
$data = array(“one”, “two” => “three”);
return (object) $data
}
I was able to restore the amphp.org website to it’s repviouse state. We are working on getting a new wiki based website launched wich should allow for better collaberation about the topic.
In AMFPHP you were able to specifiy a services directory and a VO directory. The main reason that I remember that we created a VO directory was so that the service browser did not look into that directory. Does anyone have a reason why they would want a different directory for services and VO’s? Respond quick as I am leaning towards just having a services directory!
The first byte of an AMF envelope actually does have a meaning. I was able to email with Peter Farland from Adobe tonight as I was finishing up some code rework for Zend_AMF and he explained that the first two bytes are actually one value and read as an unsigned short integer. I have updated the documentation on OSFlash. Lets see how long it takes for every opensource AMF implementation to not have code that says something like this in AMFPHP:
$topByte = $this->readByte(); // ignore the first two bytes -- version or something
$secondByte = $this->readByte(); //0 for Flash 8, 1 for FlashComm, 3 for flash player 9
Updated file for Essential Guide to Open Source Flash chapter 7. There were several files that were missing on book website. I am working on getting that updated but until then here they are! Chapter Files
Thanks to those that pointed this out:
http://wadearnold.com/blog/?p=32
I have updated the SVN repository to fix a couple issues that were found over the last couple months. If you are a major amfphp user please check out a version and test that nothing else was broken, , and that these issues where resolved for you.
Bug Fix to handle ByteArray when ByteArray already exists.
Bug Fix for PHP5 overridden ArrayAccess and ArrayObjects with an explicit type
Update to handle disk I/O of finding services faster.
Update to handle disk I/0 for class mapping faster.
, and that these issues where resolved for you. 
Recent Comments