Setting up first Lithium project

I’m now starting my first Lithium project. So I thought I’d jot down notes while playing with it. Just random stuff. I’m not trying to accomplish anything in particular with this post. It might be interesting to you if you’re planning to try it out. Especially, if like me, you’re used to Zend Framework.

So far the docs are a little better than I expected, as we aren’t yet at release 1.0. But we should expect some speed bumps.

The first thing I noticed is the suggestion to install the whole framework under the docroot. To see the homepage you go to http://localhost/lithium . I’m sure that will change though so that your application code doesn’t live under your docroot. If you’re doing anything other than development, obviously you can and should fix this in production.

Something I like about the Zend Framework coding standards is the lack of an end php tag ?>. Having been bitten by that spacing after the endtag “bug” before, it now looks weird to me to see the end tag closing up a file. Hopefully #LI3 will follow Zend’s lead on that.

If you’d like to peruse the #LI3 coding standards, they are here. Overall I really like them.

Not sure what’s wrong with casting using shortcuts. Is it really ambiguous to say (int) $var rather than (integer) $var? (not a big deal in the scheme of things though)

Side note, I wish the PHP community would come to a consensus with the underscore thing before _protected methods.

I got used to it with Zend Framework. Now there’s a poll about removing it or not and last I looked it seemed that it was going away.

I just hope everyone keeps it…or removes it…but we make a community decision so that we don’t have another of these tabs vs spaces debates for the next 10 years. Which leads me to my next point. Kudos to #LI3 for choosing correctly with tabs 😉 I thought I was in the minority about that. Certainly seems that way in the Open Source community.

One more thing. Just installed the Lithium Documentation Tool. This is so cool. Really excited to learn more.

I’m going to end this post with a little list of #LI3 RSS feeds that I started to follow. It may be updated periodically and do let me know if you know of any others:

http://nitschinger.at/
http://dev.lithify.me/lithium/wiki/blog.rss

Advertisements

Is your site slow? Come to our meetup and have experts tear your site apart!

Yes, I did just say that! No, don’t be scared. No one will bite you! We’ll just help you make your site faster.

And not only is it free, not only can it help you become a better web developer…but we often have raffles, giving away books and more.

So if you’re in Los Angeles on December 7th, RSVP here:
Meet for Speed.

Ryan Witt will be leading the session.

Live in another city? Not to worry. Just ping me or Sergey and we’ll point you to your nearest Meet for Speed location.

How to integrate HtmlPurifier with Zend Framework

It looks like I’m inadvertently starting a series on how to integrate some external libraries with Zend Framework. So be it. Next on the list is HTMLPurifier.

Like with the Amazon AWS SDK, I’m just starting the process as I write this. I have no idea how hard it will be. So let’s start with a Unit Test again and try to make it pass.

The Unit test is located at /project/tests/application/models/PurifyTest.php and contains this.

Obviously, the test will fail at this point

phpunit –configuration phpunit_local.xml –group purify

So let’s do a couple things. First, download the latest version (my link might be stale by the time you read this. So just find the latest release).

Next, if you set it up the same way I do, you’ll have a share folder in your filesystem, where you’ll put the htmlpurifier-4.2.0 folder. Then in your project/library/ folder, you’ll symlink this folder: Htmlpurifier to the location of that directory. Now if you upgrade to a later version of the purifier, you just change the symlink. Then if there’s a problem, you downgrade in two seconds…

Now open the INSTALL file in purifier. What’s this?

These optional extensions can enhance the capabilities of HTML Purifier:

* iconv : Converts text to and from non-UTF-8 encodings
* bcmath : Used for unit conversion and imagecrash protection
* tidy : Used for pretty-printing HTML

OK, well that would be nice. As I recall, tidy these days comes with PHP so if you have a recent version, you should be OK. But just in case, I’m going to fire up phpinfo.

Whew. I’ve got all three, so I’m good to go. If you don’t, then I’d suggest you install it. If you don’t know how, no better time to learn than now. Don’t be scared. It’s a breeze after the first time and you will have learned a very valuable skill that you can use in project after project.

OK let’s continue.

Having read an article or two from Juozas and Paddy, I suspect we won’t need a model or anything, but let’s not get bogged down in details. We just want to see if we can talk to HTMLPurifier, not architect an application.

So without further ado, let’s create a model called Purify.php (in the /project/applications/models/Purify.php file). Here are the contents.

Running the Unit test shows an error…ah I pointed to the wrong location. This is the correct include file:

require_once APPLICATION_PATH . ‘/../library/Htmlpurifier/library/HTMLPurifier.auto.php’;

OK, now there’s no error on the Unit Test, but we still need to make sure we can purify something.

In my case I’ve got APC opcode cache installed, so I’m going to add this include as well:

require_once APPLICATION_PATH . ‘/../library/Htmlpurifier/library/HTMLPurifier.includes.php’;

Then I’m going to create some evil html, and try to purify it. Here’s the new code:

Purify.php
PurifyTest.php

Now let’s run the unit test:

phpunit –configuration phpunit_local.xml –group purify
OK (1 test, 1 assertion)

So it looks like we’re good. However, I’m still not satisfied. There are small differences between running PHPUnit and running code on the webserver. What concerns me is that HTMLPurifier has an autoloader and I want to be sure it won’t clash with Zend Framework’s autoloader.

So this will be easy to test. It’s very similar to the PHP Unit test. We’ll just create a test controller…skip the view and just see if it errors out or not. Here’s the code.

And Bingo! Job done. Easier than I expected it. But I still hope someone finds it helpful.

P.S. From past experience, I want to add a comment. Before you nitpick about details like requiring a file in a constructor or other practices, don’t forget it’s just an attempt to prove we have no errors. I’m not trying to paint the Mona Lisa here.

How to integrate Amazon AWS PHP SDK with Zend Framework

I was really excited when I heard that Amazon released the AWS PHP SDK. They hired the developer behind CloudFusion, Ryan Parman.

Some things lend themselves well to a library, because they aren’t that fast-moving. Zend Framework’s services are extremely useful.

However, if you’ve ever attended a talk by one of the AWS devs, they inevitably reach a slide where they show you the list of products they’ve released and when. The pace is rather impressive.

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.