If you just received a copy of Flex 4 Gumbo like me you may have some issues getting something simple started. The following code shows how to make a simple remoteobject call inside flex builder 4. A couple gotchas that fooled me. First notice that you have to wrap your remoteobject call inside of the new declarations tag. Second you should notice that the MX namespace has been dropped for all components. This too took me a bit!
The Zend Framework 1.7 was released Monday just in time for the buzz to hit Adobe Max. The following are cool things that I experienced with the project at MAX 08!
Tim Buntel gave the Keynote on the second day of Adobe MAX and mentioned the Zend Amf in the keynote. This was pretty cool!
The Zend booth seemed to have a lot of traffic and if there is anyway i can get a copy of this sign i want to hang it in my office.
The Adobe Booth had these flyers laying around that talked about the integration.
Garth Braithwaite gave a presentation at 360|MAX about using Zend Amf in an application. Sorry garth we are not going to change the name the ZAMF.
James Ward and I had a little chat without cowboy hats! He was looking pretty metro sexual for being the RIA cowboy! We are going to try and get census updated to compare Zend Amf vs java. Ohh that’s going to trigger some work on AMFEXT!
The Zend Framework website updated announcing the 1.7 release and I love the Adobe advertisement!
I also got to talk with the Flex Builder team about getting better integration of PHP data services into Flex. I hope those talks go somewhere!
Super excited that the new 1.7 release of the Zend Framework is into production. It has been a pleasure to be a part of this team. The guys at Zend are A+ programmers and I have learned a lot by being able to share this experience. I have never been on a group that had as high of expectations for the completness of their code and this is why the framework is so solid. Thanks Wil, Stas, Matthew, and Adobe for a chance to work with such a fantastic group!
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.
lazy class loading or auto loading is a new feature that I added to Zend Amf that allows you to specify any number of paths that you would like your services to be loaded from. There are some advantages and disadvantages to this. First it really now works exactly like the the services directory did in AMFPHP with the addition of specifying as many directories as you want. The disadvantage is that I added setClass() initially so that you can make sure that the service is available on the first request rather than being searched, loaded, and then instantiated in the middle of an amf call. I recommend that you use setClass() for any of the methods that are needed instantly on the first request such as a DAO. The other hundred services can live happily out of memory until they are needed. Go update from the Zend Framework 1.7 trunk or just go get the new server file and place it in your Zend/Amf/ directory and addDirectories() away! Also thanks for all the suggestions!
documentation
The Zend Amf Server also allows services to be dynamically loaded based on a supplied directory path. You may add as many directories as you wish to the server. The order that you add the directories to the server will be the order that the LIFO search will be performed on the directories to match the class. Adding directories is completed with the addDirectory() method in your endpoint.
When calling remote services your source name can have underscore(_) and dot(.) directory delimiters. When an underscore is used PEAR and Zend Framework class naming conventions will be respected. This means that if you call the service com_Foo_Bar the server will look for the file Bar.php in the each of the included paths at com/Foo/Bar.php. If the dot notation is used for your remote service such as com.Foo.Bar each included path will have com/Foo/Bar.php append to the end to auto load Bar.php
There seems to be lots of questions about the best way to setup your bootstrap/endpoint/index.php file in order to work with Zend Amf. The idea of leveraging the Zend MVC framework to route to your server endpoint is a common question but personally seems like a bad idea. Although it may seem convenient it does not provide any MVC integration and second will slow down the response time of your service greatly.
I typically have something like the following structure:
Recent Comments