:: Archive for July, 2006 ::

Ajax Form Validation

Posted on July 30th, 2006 in PHP, Web Development by Greg

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:

1
2
<script src="/ajaxValidate/static/js/prototype.js"></script>
<script src="/ajaxValidate/static/js/ajaxFormValidate.js"></script>

Next, you add an ‘onSubmit’ handler to the form you’d like to validate – in this case, mine looks like this:

1
<form action="/ajaxValidate/index/success" method="POST" onSubmit="return submitForm(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:

1
2
3
4
5
6
function submitForm(form) {
	validator = new AjaxFormValidator(form,"/ajaxValidate/index/validate");
	validator.errorDisplay = 'inline';
	validator.inlineElem = 'errorDiv';
	return validator.validate();
}

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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
public function validateAction() {
	$errors = $this->getErrors($_POST);
	if(count($errors) == 0) $errors = false;
	echo Zend_Json::encode($errors);
}
</php>
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.
<pre lang="php" line="1">
protected function getErrors($values) {
	$errors = array();
	if(!Zend_Filter::isRegex($values['fname'],'/^[a-z]+[a-z 0-9-_]*$/i')) {
		$errors[] = 'First Name is required and may only contain letters, numbers, and spaces';
	}
	if(!Zend_Filter::isRegex($values['lname'],'/^[a-z]+[a-z 0-9-_]*$/i')) {
		$errors[] = 'Last Name is required and may only contain letters, numbers, and spaces';
	}
	if(!Zend_Filter::isRegex($values['email'],'/^[_a-zA-Z-]+[._a-zA-Z0-9-]+@[a-zA-Z0-9-]+\.[.a-zA-Z0-9]+$/')) {
		$errors[] = 'Email is required and must be a valid email address';
	}
	if(!Zend_Filter::isAlnum($values['password']) || (strlen($values['password']) < 6) || (strlen($values['password']) > 12)) {
		$errors[] = 'Password must consist of only letters and numbers and must be between 6 and 12 characters';
	}
	return $errors;
}

Check it out, in action. And that’s about it – pretty simple, huh?

You can download:


gCards Forum Up!

Posted on July 3rd, 2006 in gCards, PHP, Uncategorized by Greg

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

Experimenting with Google Checkout and PHP

Posted on July 1st, 2006 in PHP, Technology, Web Development by Greg

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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
require('GoogleCheckout.php');
 
$merchant_id = 'XXXXXXXXXXXXXXX';
$merchant_key = 'XXXXXXXXXXXXXXXXXXXXXX';
 
$google = new Gregphoto_Service_Google_Checkout($merchant_id,$merchant_key);
$google->setMode('sandbox');
$google->addItem('Doolittle','Doolitle CD by The Pixies (1989)','11.98',1);
$google->addItem('PSCREEN18','18 inch Pizza Screen','7.99',3);
$google->addItem('MYWIDGET01','New tax free widget - Student Use Only','149.21',1,'','taxfree');
$google->addItem('NDISC01','New Customer Discount','-10',1);
$google->editCartUrl = 'http://www.gregphoto.net/index.php?action=editcart&source=google';
$google->continueShoppingUrl = 'http://www.gregphoto.net';
$google->setShipping('UPS Ground',19.99);
$google->setShipping('UPS Next Day',27.99);
$google->setShipping('Instore Pickup',4.99,'pickup');
$google->setStateTax('CA',.0875);
$google->setStateTax('IL',.0525);
 
echo $google->getHTMLForm();
$google->printXML();

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