Graphics by Greg

Looooong time since I've written anything here - about 9 months! This time around I've put together a simple PHP5 class for communicating with the Defensio web service. Defensio has an example PHP class, but unfortunately it is PHP4 only and it's more fun to rewrite it, right?

For those who don't know about Defensio, it is a web service for determining whether a comment on a blog or message in an application is spam. To use it, you must first register for an API key. Defensio is very similar to the venerable Akismet (see the article I wrote on Akismet) but they provide a couple other features such an indication of the 'spaminess' of an individual message. Akismet has worked out great for me (123,419 spam comments caught so far!), but I figured it would be good to try out something new as well.

The class is a PHP5 class and the public methods are reasonably well commented. The bottom of this post has a link to a test application and a download of the class/test application. So...the usage of this class is quite straightforward, as shown below:

A couple key points on usage:

• Each Gregphoto_Defensio object requires an Http adapter that it will use to make Http POST requests to the Defensio web service. I originally hardcoded it to use the Zend_Http_Client from the Zend Framework, but figured this could discourage people from using it. Then I wrote up a quick adapter to use PHP's Http Stream Wrappers, but realized that didn't work on my Dreamhost account, so I added in an extra one for the Curl extension. In theory I should have added a Gregphoto_Defensio_Adapter_Interface class, but I was lazy and didn't want to add in an extra file.
• Each Gregphoto_Defensio object can be used to make many requests
• All of the current Defensio API's are covered by the class. These are covered by the following methods in the Gregphoto_Defensio class:
  • validate_key
  • announce_article
  • audit_comment
  • report_false_negatives
  • report_false_positives
  • get_stats
• Each of these methods takes a single parameter, an associative array of options as defined by the Defensio API. Each API also returns an associative array of response parameters. Two static utility methods Gregphoto_Defensio::getActions (returns a list of defensio methods such as 'validate-key') and Gregphoto_Defensio::getActionDetails (returns a list of required parameters, optional parameters, and response parameters for a specific Defensio action) are provided in order to get the details of the input and output parameters.

I created a simple test application which can be used to test Gregphoto_Defensio and all of the APIs provided by Defensio.

Download the Gregphoto_Defensio class and the test application

I put together a simple, lightweight PHP class for generating thumbnail images. The class is compatible with PHP5 and uses the GD2 extension (included by default with PHP5) to create JPEG, PNG, and GIF thumbnails. I've setup a Google Code project for it: Gregphoto_Image where you can checkout the source from SVN and file bugs.

The class has the following basic features:

• Ability to read JPEG, PNG, or GIF images
• Ability to output JPEG, PNG, or GIF images
• 4 modes of thumbnail creation
  • MAX_HEIGHT - you specify a maximum height and the dimensions are calculated based off of the height
  • MAX_WIDTH - you specify a maximum width and the dimensions are calculated based off of the width
  • BEST_FIT - you specify a maximum height and width and the dimensions are calculated so that the thumbnail
    is as large as possible without exceeding the maximum height or width
  • EXACT - you specify a maximum height and width and these are directly used. Causes distortion if the
    chosen aspect ratio is different from the aspect ratio of the image
• Renders/saves images in their input format by default, but allows changing the format. For example, input a GIF but output a PNG
• Fully documented object oriented code
• Fluent interface for creating thumbnails with a minimal amount of code

The class is licensed under the MIT license, which basically means it can be used and modified by anyone - for personal or commercial use.

You can Download it from the project page on Google Code. You can view examples of it running on my site - the examples are checked into SVN and can be viewed on the project site. You can also view the docs.

Example usage:

Enjoy!

Recently I put together a reusable Ajax form validation component that I'd like to share. It is a JavaScript object that collects the values of all of the elements in a form, sends it for processing to the server, and displays any errors. If there are no errors it submits the form. There are several benefits to this approach

• Allows you to perform complex validation, such as verifying the uniqueness of a username, or checking something in the database...all without reloading the page
• Allows you to use the same validation routine for both client-side validation and server-side validation
• Reduces the amount of client-side code needed for validation

The JavaScript used in my example requires the Prototype library. My example uses PHP to perform the validation - more specifically, I've used several components of the Zend Framework (PHP5 only). The example uses:

• Zend_Controller_* classes including the new RewriteRouter to handle the routing within the application
• Zend_View to handle the output
• Zend_View_Helper_* classes to build form elements
• Zend_Config to read in configuration options
• Zend_Filter to perform several field validations
• Zend_Json to serialize PHP variables/objects to JSON objects

Did I need all of this stuff on the server-side to put together a simple form validation example? Heck no, but when I'm experimenting with new stuff I like to use a lot of new components so I can learn more about them and be prepared for when I actually do need to use all of this fire power. I've been following the Zend Framework carefully, so I wanted to use some of the stuff I hadn't used yet - particularly the controller architecture.

The HTML and JavaScript

Ok, back to how this JavaScript is used. It's actually really quite simple. First, you need to include the JavaScript files for both Prototype and AjaxFormValidator in the head of your HTML document:

Next, you add an 'onSubmit' handler to the form you'd like to validate - in this case, mine looks like this:

The form action is set to the page I'd like the script to go to if the validation is successful. The onSubmit calls a custom function that we still need to define. It passes 'this' as an argument - the 'this' refers to the form element itself.

Now we define the submitForm() function that the onSubmit of the form will call - it looks like the following:

This function first creates a new AjaxFormValidator object, passing it the form element (or the form id) and the url the validation request should be sent to. The next two lines setup the type of error display that should happen. The following error display types are supported:

• alert: The default option. Displays all errors in a JavaScript alert box.
• inline: Displays errors within an element that is defined on the page. You need to set the element name with validator.inlineElem. In this example, errors will be shown in a div with id="errorDiv".
• none: errors won't be shown to the user. The will be available as an array of errors in the errors property of the validator (i.e. validator.errors). If there are no errors the property will be set to false. Once you have the errors you can perform more advanced error handling/display to the user.

Lastly, validator.validate() will send the values in the form, in an HTTP POST, to the validation url you've provided (/ajaxValidate/index/validate in this case). If there are no errors the form will be submitted, if there are errors the will be shown (or not shown if you've chosen 'none' as the errorDisplay).

The PHP

Once the request is sent it will eventually arrive at the server for processing - in this case, through the magic of routing, it is going to end up in my IndexController in the validateAction method. This function is shown below:

This function calls another method within the IndexController class called getErrors, passing in the entire array of POST arguments (values in the form). It receives back an array full of error strings. If there are no errors, it changes the value of the $error variable to false. Lastly, it uses Zend_Json to convert the PHP array/Boolean into the equivalent JavaScript array/Boolean. This string is printed and sent back to the client.

The getErrors function itself is very straightforward - it just does a couple validations and returns back an array of the errors.

Check it out, in action. And that's about it - pretty simple, huh?

You can download:

• The JavaScript
• The whole PHP project

Many folks have complained since I took down the forum that was up for the support of gCards. Now, I've got a new forum up, this one powered by Vanilla. Hopefully it'll do a bit better than the last one.

Check it out

Having put together a couple websites (Redstone Studios and Althea) that integrate with Paypal for providing checkout capabilities, I was very interested to look at Google Checkout when it was released this past week. My experience with the Paypal integration was not so good - while I eventually got it to work, it took a ton of experimentation, searching for documentation, and guessing why things weren't working (i.e. no meaningful error messages). Luckily, Google Checkout doesn't seem to suffer from these problems - I had it up and running in no time and it seems very solid for what it does. What does it do? Well, it's basically a checkout system where you can pass in a cart, users can pay by credit card, and then the money gets deposited in your bank account. Google charges 2% of the transaction amount plus twenty cents. The two percent covers the percent Google has to pay the credit card companies, and the twenty cents is some extra cash for Google. If you use Google Adwords, you get a free credit on Google Checkout - for every 1 dollar spent on Adwords you get 10 dollars of sales with no costs.

Google provides sample PHP code for getting the integration going, but unfortunately the code is PHP4 only, and it is ugly ugly ugly code. I decided to put together a simple class that allows simple integration with Google Checkout. The class is PHP5 only because it uses PHP5's DOM extension.

To use Google Checkout you need to create a Google Checkout account. From there, you can get your merchant id and merchant key, both of which are needed to communicate with Google Checkout. The Google Checkout API works by POSTING XML over HTTP. While Google's API is very flexible, I've chosen to implement a subset that I think would be useful for many people. Also, I've only implemented this class to support the creation of the cart and submission to Google, I haven't included any functionality for greater integration. This greater integration would involve creating web services that Google could call to update the website on changes to the order status, shipping, etc. The way I've set this up, all of that is skipped, and store owner would receive orders via email or Google's Checkout interface.

Limitations:

• No support for cart expiration
• No support for merchant calculations for tax/shipping/gift certificates as these require HTTPS and I don't have it and don't care to use it
• No support for requesting the buyers phone number because I didn't notice that field until just now!
• No support for shipping restrictions - i.e. shipping option 1 is only available in these zip codes/states/etc
• No support for complicated tax rules. Tax can be setup on a state by state basis. One alternative tax rule 'taxfree' is setup to allow certain items to be tax free. No support for other alternative tax rules.
• Currently doesn't support customization of the form and checkout image

In order to work around some of these limitations, I've provided a method called setDefaultXML which allows the developer to specify a default XML file to be used. The class will then fill in the items, do the encryption, and generate the form and checkout image. This allows much greater flexibility and support for all of Google's options, when needed.

Here's a simple example of how I might use it:

Now, for what's going on:

• Line 1 includes the class
• Lines 3 and 4 setup variables for the merchant id and merchant key
• Line 6 instantiates the class, passing in the merchant id and key
• Line 7 sets the class to use the Google Checkout Sandbox - this is a testing sandbox where you can setup fake accounts to use while creating your site. Paypal offerers a much richer sandbox functionality.
• Lines 8-11 add new line items to the cart, setting there name, description, price, quantity, notes, and special tax rules
• Lines 12 and 13 setup the URLs the user should be sent to if the choose to edit the cart or continue shopping
• Lines 14-16 setup various shipping options including their prices
• Lines 17 and 18 setup taxes for the users in specific states. Google Checkout supports much richer rules around taxation, but I kept it simple on a state-by-state level.
• Line 20 outputs the HTML form and checkout image that will send the cart to Google Checkout and bring the user to the Google Checkout page
• Line 21 shows the XML cart, for debugging purposes

View this example running on my site
View the API of Gregphoto_Service_Google_Checkout
Download the class and API docs
View Google's Develper Guide for Google Checkout