I’ve been working on a project, which started on 1.2.7, for almost 6 months now and have been upgrading it religiously along the 1.2.x branch which stopped at 1.2.10. We’re currently entering the testing stage, and being as curious as I am opted to create a 1.4 branch from the current trunk and started the upgrade process while merging fixes from the trunk as fixes come in. We’re using the PEAR-based approach which allows us to quickly upgrade the base installation as soon as a new release comes in. Although i’m planning to migrate it to the subversion approach soon, but thats another blog post.

So lets start with the upgrade, symfony 1.4 and 1.3 is basically the same feature-wised but the former lacks the backwards compatibility that the latter provides, basically 1.3 is just a stepping stone to upgrade to 1.4. The Symfony team really did a great job on the seamless upgrade process. Also to have a better background on the upgrade process read the upgrade document from their website (http://www.symfony-project.org/tutorial/1_4/en/upgrade). Ok, so lets start with the upgrade.

Lets uninstall symfony 1.2

pear uninstall symfony/symfony

Then install symfony 1.3

pear install symfony/symfony-1.3.1

Once installed, make sure to upgrade the plugins, rebuild the models, and clear the cache to make sure you’re using the new files. Now you can opt to continue upgrading to 1.4 and drop the backwards compatibility or just stick with 1.3 for the time being, both of which are being supported but 1.4 is a LTS release, meaning that it has a longer support period than 1.3. Before upgrading to 1.4 it is important to remove old class files, symfony provides a build-in task to ease the transition. Just execute this command and symfony will list down all of the deprecated stuff that should be remove/modified, they also provided documentation on what to replace the deprecated stuff with (http://www.symfony-project.org/tutorial/1_4/en/deprecated)

symfony project:validate

So now that you’ve removed/modified all of the deprecated stuff, upgrading is quite similar to 1.3.

Remove the old symfony installation

pear uninstall symfony/symfony

Install the new one

pear install symfony/symfony-1.4.1

Then just clear the cache. Also the freeze/unfreeze task has been removed in 1.4; it may or may not be important to you but I use it when deploying to our servers, one quick fix is to just create a lib/vendor folder and copy/paste the symfony folder found in your PEAR installation folder, and then modifying the include call in the config/ProjectConfiguration.class.php file. So now you have a easily upgradable and independent symfony installation inside your app.

Been giving this alot of thought lately. What to use for my next project. Ever since symfony 1.2′s move to Propel 1.3, the major argument of speed against Propel has been solved with its migration out of creole and into PDO. So speed is definitely at par with Doctrine, but the curious side of me wishes to delve into something new to mix things up a bit.

What to use? Doctrine or Propel?

I was initially skeptical about these numerous form frameworks that are coming out, I would initially opt to create forms and validations the old fashion way, but after giving symfony forms a shot; I can honestly say i’m converted! Lets start the tutorial by creating a basic registration form with a captcha. I would assume you know the basics of symfony if not go to their website (http://www.symfony-project.org) and check out their tutorial.

After setting up the project, app and modules we will install the plugin sfFormExtraPlugin so we can use ReCaptcha:

symfony plugin:install sfFormExtraPlugin

After that, go to http://www.recaptcha.net and register to acquire a public and private key; we’ll use that later. Now lets start creating the form class

class RegistrationForm extends sfForm {
const PUBLIC_KEY = 'PASTE YOUR PUBLIC KEY FROM RECAPTCHA';
const PRIVATE_KEY = 'PASTE YOUR PRIVATE KEY FROM RECAPTCHA';

public function configure() {
$this->setWidgets(array(
'username'=>new sfWidgetFormInput(array(), array('size'=>32)),
'password'=>new sfWidgetFormInputPassword(array(), array('size'=>32)),
'confirm_password'=>new sfWidgetFormInputPassword(array(), array('size'=32)),
'email'=>new sfWidgetFormInput(array(), array('size'=>32)),
'captcha'=>new sfWidgetFormReCaptcha(array(
'public_key'=>self::PUBLIC_KEY
))
));

$this->widgetSchema->setNameFormat('register[%s]'); //this acts as a namespace and also will be use later for binding POST

$this->setValidators(array(
'username'=>new sfValidatorString(array('max_length'=>50), array('max_length'=>'Max length of username is 50')),
'password'=>new sfValidatorString(),
'confirm_password'=>new sfValidatorString(),
'email'=>new sfValidatorEmail(),
'captcha'=>new sfValidatorReCaptcha(array('private_key' => self::PRIVATE_KEY), array('captcha' => 'Didn\'t match captcha'))
));

$this->validatorSchema->setPostValidator(new sfValidatorSchemaCompare('password', sfValidatorSchemaCompare::EQUAL, 'confirm_password', array(), array('invalid' => 'Passwords do not match')));

$this->widgetSchema->setLabels(array(
'username'=>'Username',
'password'=>'Password',
'confirm_password'=>'Confirm Password',
'email'=>'Email Address',
'captcha'=>'Captcha'
));
}
}

The code in your actions.class.php would be as follows

public function executeRegister(sfWebRequest $r) {
$this->form = new RegistrationForm();
if($r->isMethod('post')) {
$captcha = array(
'recaptcha_challenge_field' => $request->getParameter('recaptcha_challenge_field'),
'recaptcha_response_field'  => $request->getParameter('recaptcha_response_field'),
);

$this->form->bind(array_merge($request->getParameter('register'), array('captcha' => $captcha)));
if($this->form->isValid()) {
$values = $this->form->getValues(); //associative array of values
//you can access the POST data like $values['username'] or $values['email']
//do database insertion or other processsing here
}
}
}

And lastly displaying the form in your corresponding template would be as follows

<?php echo $form ?>

In the next article, we would be discussing how to customize your form layout.

Well that was fast, new maintenance release of Zend Framework is now out! Checking out the changelog, noticed this little gem: Addition of module generation capabilities to Zend_Tool; I posted about that in my initial thoughts of ZF 1.8 post.

I started using 1.8 on a new project recently, while actual hands-on usage of the new stuff (Zend_Application, Zend_Tool) and the documentations are great, there are still some confusion with regards to how the Resource Autoloader works, there are some conflict with the quick-start tutorial from Zend and the actual reference documentation. According to the documentation, Resource Autoloader should work automatically when using Zend_Application, but according to the quick-start tutorial, you have to initialize it in the Bootstrap. Maybe i’m missing something, but I’ve decided to go with the quick-start tutorial for the time being since it works. I’ve also noticed that there are some new view helpers like ($this->cycle for one) minor stuff but very helpful!

Using Zend_Form is still an exercise in frustration, especially the decorators. I love the way symfony handles the form layouts, it just passes the form object as an array to the view layer and gets out of the way, allowing designers to actually do the form design. Zend_Form just seems counter-intuitive. They got majority of the stuff correct, but laying out the forms to display how you want them is very hard. Let the view layer handle the layout stuff, allowing the Form object to be more flexible and reusable.

Been playing around with the new version of Zend Framework (1.8). The command line Zend_Tools has alot of potential and is very useful for newbies, but still lacks a lot of functionality (support for modules in the command line would be pretty cool!). I loved the Application/Bootstrap approach this puts a lot of much needed structure to a very flexible framework. It also centralizes plugins to the front controller and of course custom initializations using _init methods in the Bootstrap file. Although missing in the reference documentation are examples when using a more modular approach when using the Zend_Application.

Also the quick-start tutorial from Zend’s website has been updated! It includes a very nice approach to models (much needed overhaul in the next version of ZF). Overall a very solid release from the community. Looking forward to using it in new projects.

I’m not really a big fan of Zend_Form, too verbose and less flexible. I’ve been using this little base class for several of my freelance projects. It basically allows you to define validation rules for your model’s columns. This is a very basic version that I’m planning to enhance soon with custom validation functions.

Download version 0.1

USAGE EXAMPLE

Model

<?
class User extends AbstractModelValidator {
	protected $_name = 'users';
	protected $_primary = 'id';
	protected $_rules = array(
		array('name'=>'firstname', 'class'=>'NotEmpty', 'message'=>'Required Field (Firstname)'),
		array('name'=>'firstname', 'class'=>'StringLength', 'options'=>array(0, 50),'message'=>'Max length is 50 (Firstname)'),
		array('name'=>'lastname', 'class'=>'NotEmpty', 'message'=>'Required Field (Lastname)'),
		array('name'=>'lastname', 'class'=>'StringLength', 'options'=>array(0, 50),'message'=>'Max length is 50 (Lastname)'),
	);
}

Controller

<?
class UsersController extends Zend_Controller_Action {
	public function addAction() {
		$this->view->req = $this->_request;
		if($this->_request->isPost()) {
			$u = new User();
			if($u->isValid($this->_request->getParams())) {

			}
			else {
				$this->view->errors = $u->getValidationMessages();
			}
		}
	}
}

View

<html>
	<head>
		<title>Add User</title>
	</head>
	<body>
		<? if(isset($this->errors) && sizeof($this->errors) > 0): ?>
			<ul>
				<? foreach($this->errors as $e): ?>
					<li><?=$e?></li>
				<? endforeach; ?>
			</ul>
		<? endif; ?>
		<div>
			<form action="<?=$this->url()?>" method="post">
				<div>Firstname:</div>
				<div><?=$this->formText('firstname', $this->req->getParam('firstname'), array('size'=>20))?></div>
				<div>Lastname::</div>
				<div><?=$this->formText('lastname', $this->req->getParam('lastname'), array('size'=>20))?></div>
				<div><?=$this->formSubmit('submit', 'Submit')?></div>
			</form>
		</div>
	</body>
</html>

I use alot of Zend Framework for my freelance projects and prior to version 1.6 they have no pagination class to do the dirty work. I know what you’re thinking right now, why didn’t I just reused some of the many pagination scripts in the internet and/or in PEAR. I just really needed something simple that I can quickly reuse all over my web-app and here it is

To get the offset for your sql query just do this:

$offset = $numOfItemsPerPage * ($page - 1);

Here’s the code for the pagination, take note that the logic can be use regardless of the programming language, i’ve also use this in some of my java webapps

<?php
class Paginator {
	const NUM_TRAIL_LEAD_LINKS = 5;

	public static function generate($url, $total, $current = 1, $numPerPage = 5, $var = 'page', $separator = ' ') {
		$totalNumberOfPages = ceil($total / $numPerPage);

		$linksArray = array();
		$isFirstLinkDone = false;
		$i = 1;
		if(($current - self::NUM_TRAIL_LEAD_LINKS) > $i) {
			$i = $current - self::NUM_TRAIL_LEAD_LINKS;
		}

		for(;$i<=$totalNumberOfPages;$i++) {
			if(!$isFirstLinkDone && $current > 1) {
				$linksArray[] = '<a href="'.$url.'/'.$var.'/1">First</a>';
				$linksArray[] = '<a href="'.$url.'/'.$var.'/'.($current-1).'">Prev</a>';
				$isFirstLinkDone = true;
			}

			if($i == $current) {
				$linksArray[] = '<span style="font-weight:bold">'.$current.'</span>';
			}
			else {
				if(($current + self::NUM_TRAIL_LEAD_LINKS) < $i) {
					break;
				}

				$linksArray[] = '<a href="'.$url.'/'.$var.'/'.$i.'">'.$i.'</a>';
			}
		}

		if($current < $totalNumberOfPages) {
			$linksArray[] = '<a href="'.$url.'/'.$var.'/'.($current+1).'">Next</a>';
			$linksArray[] = '<a href="'.$url.'/'.$var.'/'.$totalNumberOfPages.'">Last</a>';
		}
		return implode($separator, $linksArray);
	}
}

A few months ago I was doing some job hunting and i’ve come across some interesting job interviews in the process. Now I have a good mixture of full-time work and freelance work, and most of my freelance work consists of enterprise PHP web applications; while my full-time work primarily consists of J2EE and Oracle.

During the course of the interview when they are finished asking me the standard questions regarding my J2EE and Oracle experience, they focused their attention on my freelance works. I must say there is a really big ignorance with the LAMP stack in the enterprise world, opinions and questions that PHP is only a toy language and it cannot “scale” like their “100 concurrent users or the app server will choke” J2EE apps.  Now this opinions are nothing new, but it’s hilarious when you actually meet people with that opinion. If only they knew that sites like Digg, Facebook, Friendster were constructed with PHP albeit the web-part only, but like they say, right tools for the right job. I cringe everytime people construct simple intranet sites with full blown J2EE architecture thinking it would automatically scale because it’s Java/Oracle; apps that could have been simply done with a LAMP stack and 1 week.