One thing that was giving me some problems though, was displaying error messages. It is always nice to give good feedback to your users with a nice, meaningful message about what was wrong with the input they provided.

To accomplish this, I build the form, consisting of a first name, infix, last name and email address.
Before reading on, I must mention that wordpress screwed up my code formatting, but your IDE should be able to make something good out of it.


$this->setAction($this->_actionUrl)
->setMethod('post')
->setAttrib('id', 'signupform')

$this->addElement('text', 'firstname', array('label' => 'First name'));
$username = $this->getElement('firstname')
->addValidator('alnum')
->setRequired(true)

$this->addElement('text', 'infix', array('label' => 'Infix'));
$username = $this->getElement('infix')
->addValidator('alnum')
->setRequired(false)

$this->addElement('text', 'lastname', array('label' => 'Last name'));
$username = $this->getElement('lastname')
->addValidator('alnum')
->setRequired(true)

$this->addElement('text', 'email', array('label' => 'Email address'));
$email = $this->getElement('email')
->addValidator('EmailAddress')
->setRequired(true)

$submit = $this->addElement('submit', 'Signup');


I can now stick this into my views using:
Controller:
$form = new SignupForm('/user/signup');
$this->view->form = $form;
View:
<?php echo $form; ?>
Refreshing the page should now give you a simple form with a submit button. This form does nothing now though, and we could use some interaction at the end:
public function signupAction() {
$form = new SignupForm('/user/signup');
if ($this->_request->isPost()) {
if ($form->isValid($this->getRequest()->getPost())) {
echo "Congratulations, your form validated";
}
}
}
As you can see here, we are actively checking if the form was indeed valid. Remember the validators we added to the form? The Zend Form is smart enough to iterate over the elements with values from the POST and decide whether or not the input is valid. It doesn’t stop there though, it continues iterating until the end, all the while collecting error messages from the validated input.
Before displaying what was wrong with the user’s input, we must first add these messages somewhere. We add them to the form, as that is where they belong:
$this->addElement('text', 'firstname', array('label' => 'First name'));
$username = $this->getElement('firstname')
->addValidator('alnum')
->setRequired(true)
->addErrorMessage("Something was wrong with your first name");

$this->addElement('text', 'lastname', array('label' => 'Last name'));
$username = $this->getElement('lastname')
->addValidator('alnum')
->setRequired(true)
->addErrorMessage("Something was wrong with your lastname");

$this->addElement('text', 'email', array('label' => 'Email address'));
$email = $this->getElement('email')
->addValidator('EmailAddress')
->setRequired(true)
->addErrorMessage("Something was wrong with your email");

These messages could be nicer and could even be retrieved from a language table if you want. You could also add messages that are returned depending on what kind of validation went wrong.
For now, let’s leave it this way and display the messages to our user:
if ($form->isValid($this->getRequest()->getPost())) {
// Your validated form code
else {
$messages = $form->getErrors();
$this->view->formResponse = $messages;
}
This was what stomped me a little in the beginning. The form has a method called getErrorMessages() and since we added the messages to our form elements using addErrorMessage(), it seemed only logical to retrieve these with aforementioned method. For reasons unknown to me, the Zend team decided it was best to use getErrors().

Feel free to make this prettier and perhaps trow in some AJAX to make this more dynamic.

And a form with a couple of fields which eventually calls this method:

public function signupAction() {
$this->view->title = 'Signup';
$form = new SignupForm('/user/signup');
$this->view->formResponse = '';
if ($this->_request->isPost()) {
if ($form->isValid($_POST)) {
$signupdate = new Zend_Date();
$client = new Zend_Rest_Client('http://localhost:8080');
$data = array('surname'=>$this->_getParam('firstname'),
'infix'=>$this->_getParam('infix'),
'lastname'=>$this->_getParam('lastname'),
'email'=>$this->_getParam('email'),
'signupdate' => $signupdate->toString('yyyy-MM-dd hh:mm:ss'));
$response = $client->restPost('/yourapp/signups', $data);
} else {
$this->view->formResponse = 'Sorry';
}
}
$this->view->form = $form;
}


This should not be too hard to use in your own application. If you need more explanation or more of the code I used, please ask in the comments.

Edit: I see wordpress messed up the code blocks, so for a more easy-to-read version, check the both gist files

A standard stub containt PHP code that allows a phar file to also run on PHP 5.2 installations. As the 5.2 version does not come with the phar extension build-in, this piece of code needs to jump some hoops in order to be able to run the phar file. This shows in the file size: the stub is about 7KB of PHP code.

If you remove references to the standard stub and only use that what is necessary for PHP 5.3, the performance increases to a rate which is comparable to webapplications that are read directly from the file system:

<?php
$phar = new Phar('project-0.1.phar', 0, 'project.phar');
$phar->buildFromDirectory('project/');
$phar->setStub("<?php
Phar::interceptFileFuncs();
set_include_path('phar://' . __FILE__ . PATH_SEPARATOR . get_include_path());
Phar::webPhar(null, \$web);
include 'phar://' . __FILE__ . '/' . Extract_Phar::START
return;
__HALT_COMPILER(); ?>");
?>


• The concept of “current directory” has no meaning in a stream wrapper
• chdir() and getcwd() only work for directories stored on physical disks. All references to chdir() or getcwd() therefore needed to be modified by hand.
• All uses of opendir() that reference internal application code had to either use dirname(__FILE__) or be hand-modified.

So check if your application isn’t affected by the above issues.

First, we need to create a PHP script that handles the phar creating for us. Other then the Java counterpart, PHP allows for more configuration about how a phar file is created.
We could call this file makephar.php:

<?php
$phar = new Phar('project-0.1.phar', 0, 'project.phar');
$phar->buildFromDirectory('project/');
$phar->setStub('<?php Phar::webPhar(); __HALT_COMPILER(); ?>');
?>

This piece of code creates a phar called project-0.1.phar with an alias of project.phar, adds all the content of ‘/’ and creates a webPhar; more on that later.
If you execute this from your command line:

$ php -d phar.readonly=0 build-phar.php

Or from a browser if the file is publicly available (not secure though), you’ll see that the phar file is created and ready to be used.

You can now deploy this file to your apache documentroot and call it from the browser. This can be done by either adding support for phar files to apache:

AddType application/x-httpd-php .php .phtml .phar

Or by renaming the phar file to a PHP file and calling that. The Phar::webPhar() method parses $_SERVER['REQUEST_URI'] and routes a request from a web browser to an internal file within the phar archive. In essence, it simulates a web server, routing requests to the correct file, echoing the correct headers and parsing PHP files as needed. This powerful method is part of what makes it easy to convert an existing PHP application into a phar archive.
You can now start playing around with APC or other caching mechanisms to speed things up, but I’ll leave that up to you.

Other things you can do with Phar files include easy deployment, for example with capistrano and automate the entire process. This could be coupled with you SVN tags to automaticaly create and deploy a phar on a test site upon creating a new SVN tag.
I also see a brighter future for those web-ftp-and-edit-online scripts, which normally pose somewhat of a security-threat while not adding much-needed functionality. Similar to Apache Tomcat’s manager, a apache manager could be made where it would be easy to drop-in your application and perhaps even have it run sandboxed.

Let your fantasy run free and share your ideas about what Phar can bring us

My tests confirmed what the user reported and I quickly saw that the table was setup as a ‘latin1_swedish_ci’ collection (why Swedish is beyond me). I changed this to ‘utf8_general_ci’ and restarted my tests, expecting a fix. Experienced users in this field already know: it didn’t work. Even changing the individual column collections from ‘latin1_swedish_ci’ to ‘utf8_general_ci’ didn’t help. There seemed to be a mismatch between the unicode the database used and the unicode the application was using.

A quick google search let me to the MySQL docs and pointed me into the right direction. The fix was to explicitly set the client character set after making a connection, but before any query was done.
Ultimately, the code looked like this:

mysql_connect( $this->m_host, $this->m_mysqluser, $this->m_mysqlpassword ) or die("Could not connect to MySQL database");
mysql_select_db($this->m_db);
mysql_query("SET NAMES utf8");

Althoughthis works perfectly, this doesn’t seem like a clean solution though. So if there is anybody out there with a better solution, don’t hesitate to leave a comment.