When I say better documentation I don’t mean it was somehow bad before. The difference is that now the doc pages are version specific, and this is particularly good for those working with older versions of the framework.

In fact most of the cases are just like that, whether because it’s difficult to migrate some code that’s already too different from the original framework itself or because the new version is considered “not so stable”.

Whatever the reason is the version specific docs will be received very well from the community.

What are validators?

In very very breve these are methods which can validate some data, usually user input, against some specific rules. Imagine there’s a web form that is always checked for empty fields or some fields that may contain valid e-mail addresses. This is so common that became everyday routine to almost all of us. However smart developers make abstractions that help them reuse all this functionality. Even smarter developers make use of frameworks. And for those of you, using Zend Framework, there’s no need to write most of the common used validators, simply because they come with the framework itself.

Technically you’ve various validators in zend, such as Zend_Validate_Alnum, Zend_Validate_Email or Zend_Validate_Regex. All these are extremely useful when it comes to automatic, bullet proof validation, but I’m going to talk more about one specific validator.

Zend_Validate_Db_RecordExists

Although the implementation is nothing more than just a chunk of code and doesn’t pretend to be difficult, the idea of such validator is genius indeed. It really helps you do some amazing job.

Image you have to check some database record existence. Then comes in help this validator. In fact I’m pretty sure almost everyone has experience with such kind of task. Simply because the registration process almost always requires it. When you try to register new user you more often check for the username existence. Although you may solve the problem with other technique by catching the exception the database is throwing for duplicate entries, this should be assumed just as an example.

I’m pretty sure this validator can be really useful in many occasions!

Although the documentation of Zend Framework is one of the most well structured documentation I’ve ever read it happened to me to stuck into it. And that happened exactly when I tried to use the date component of ZF – Zend_Date.

Why I’d prefer Zend_Date?

We all know what the date function of PHP is, and what it does. It has reach set of formating string that help you do the job but as I’m working mostly on multilingual projects almost every project needs multilingual dates, and more or less nobody wants only numbers into the dates. And all this is pretty natural, instead of using the simple

01.01.2010

format, which beside it’s natural ugliness is not clear. Because as you may know in the US this can be understood as month.date.year, while in Europe this is date.month.year. And when it comes to dates like 02.01.2010 this can be really frustrating.

Beside this ugly format, you can choose to format your dates either with:

1 January 2010 or 1 Jan 2010

which is clear enough, but it’s only for english speakers. You know that in a spanish speaking country you should format the same date as:

1 Ene 2010

where “ene” means enero – january in spanish. How should you overcome this natural PHP problem?

Well the answer is by using Zend_Date

The problem I found in Zend_Date usage is that the native copy/paste technique from the doc page doesn’t seem to work. What the doc page says you is:

// setup the default timezone
date_default_timezone_set('Europe/London');

and than you can simply request a date with:

$date = new Zend_Date(‘2010-01-02’);
echo $date->get('d MMM yyyy');

where this should print 1 Jan 2010.

It’s a shame that this doesn’t work. The good part is that this problem can be overcome very simply. You just need to setup some more things just before calling the get method.

First setup a cache mechanism where you can cache the date locales. This is really good practice because it speeds up the framework when dealing with dates. Just add those lines after the default timezone is set:

// setup the default timezone
date_default_timezone_set('Europe/London');

$locale = new Zend_Locale(‘es_ES’);
Zend_Registry::set('Zend_Locale', $locale);

$frontendOptions = array(
		'lifetime' => 600, // 10 minutes
		'automatic_serialization' => true
);

$backendOptions = array(
                'cache_dir' => '../cache/'
		);

// getting a Zend_Cache_Core object
$cache = Zend_Cache::factory('Core',
		             'File',
		              $frontendOptions,
		              $backendOptions);

First you setup the Zend_Locale – a locale for the entire application and set it up in this example for spanish, than setup the cache mechanism.

This is a typical cache setup for Zend Framework. If you’d like to dive more into cacheing you can checkout the doc pages for Zend_Cache.

After these lines just setup Zend_Date options with:

Zend_Date::setOptions(array('format_type' => 'php',
                   'cache' => $cache));

This is really what you need to do to start. All these lines of code you may place into the bootstrap.php or into some front controller plugin.

Then you can call Zend_Date’s get method wherever you’d like in every controller you need it!

Recently I posted about the redirecting mechanism of Zend Framework. It’s a working chunk of code but the problem is that it seems quite difficult in according with other ZF sample codes.

Yes the same goal can be achieved with less effort. Like the _forward function which just executes other action/controller, you can call the _redirect method to rewrite the URI.

Just use that in any action of any controller:

$this->_redirect('http://www.example.com');

That executes exactly the same as calling the header PHP method or echoing the <meta> refresher!

First of all, let me introduce you to my case. I’m working on a Mac with both Xampp and Zend Server CE. Both have separate MySQL servers installed from their default installation on my machine. Both have their separate phpMyAdmins.

The one thing I couldn’t find in the man page of Zend Server CE is how to I access this MySQL server installation from my PHP scripts.

The answer is quite simple – trough UNIX socket. The ZS CE default db socket is:

/usr/local/zend/mysql/tmp/mysql.sock

and yet again let me say that this is for Mac.