Some things lend themselves well to a library, because they aren’t that fast-moving. Zend Framework’s services are extremely useful.
Even Zend, with a huge list of contributors, will have a tough time keeping up. As Till says, this is a situation where you want Amazon to support the AWS service code.
Unfortunately, you can’t just drop the SDK into your library and integrate it with Zend Framework. I haven’t fixed all the details yet, but my goal as I write this is to get a PHP Unit Test to pass.
If you don’t plan to use this for awhile, just wait, as Ryan is planning to work on integrating with Zend.
This is an early release of the SDK and there are a couple of things that bothered me a bit, but I’m sure they’ll fix it up. To give you an idea, I’ll just quote Harold on the blog’s announcement page:
I have to be frank, there is lots of room for improvement in this SDK. Where are the unit tests? Also, what’s up with the file naming convention, and having multiple classes per file? This prevents us from using class autoloading. I’m not sure what format the docblock comments are in, but they sure aren’t standard PHPDoc, and therefore do not integrate with NetBeans/Zend Studio/etc. Also, the CFUtilities class could at least contain static methods, eliminating the need to instantiate it.
OK, let’s begin. Download the SDK here. Or use Pear. Assuming you’re using the recommended Zend Framework project directory structure, create a directory called Aws under your library folder. Drop the files from sdk-1.10 in there.
I haven’t totally figured out how I’m going to be using the SDK yet, so for now I created a Model called Model_Aws. Unfortunately, the SDK wants you to modify their sample configuration file and rename it config.inc.php.
As you know, in Zend Framework we have a config file that allows us to offer up different values depending on environment. So we aren’t too interested in using another, less flexible, config file.
Fortunately, you can pass the config data into the constructor. We want everything of value from the SDK’s config file to be in our application.ini file.
So what I did was, where the SDK has “define(‘AWS_KEY’, ”);”, in application.ini I put “aws.key = my_key_here”. Same concept for all the other constants, with the exception of “define(‘AWS_ENABLE_EXTENSIONS’, ‘false’);” which I’ve left in the SDK config file. Comment out or delete the constants from the SDK config.
If I just lost you, that’s because I’m assuming you’ll put some effort into figuring out how to find your keys. This is not a beginner’s tutorial or for people unfamiliar with Amazon AWS… OK, where was I?
Before I show you where my Model_Aws class stands for now, I want to mention that for convenience I put my config in the Registry. So this method is in my Bootstrap.php.
I haven’t been able to get beyond including the sdk file, because of errors, so my Model_Aws class (filename /path/to/models/Aws.php) has only this in it. We’ll add more as soon as I can run a Unit Test without error.
My unit test is in /path/to/tests/application/models/AwsTest.php. Here’s the contents. OK, on the command line I run:
phpunit –configuration phpunit_local.xml –group aws
and Woaw! I get an html file getting spit out onto the console. Not good.
So open your phpunit.xml file…you should have an exclude section. In there add this in order to exclude /path/to/library/Aws . This way PHPUnit won’t go through the files in there to generate the code coverage report.
Now try. And…Bingo! Test passes.
OK let’s figure out something useful to do now. How about we just take the S3 sample that the SDK comes with, modify it a touch and just create a unique bucket and upload some files…and count that we have as many files as we created.
Now this isn’t necessarily the most useful unit test ever, but my whole purpose was just to prove that I got the SDK playing nicely and my unit tests now pass. Here is the final version of the Model_Aws and AwsTest.php.
Got any questions? Post a comment below or ping me at http://twitter.com/joedevon.