Posts tagged 'zend'

A Zend_Captcha example

published on October 22, 2008.

Update: I made an error in the example code, regarding the CAPTCHA image URL. I’m sorry for any troubles caused by this mistake.

Update #2: Here’s an example of using Zend_Captcha without the whole Zend Framework stuff.

Update #3: There was an unintentional error in the captchaAction() method, Adam warned me about it in the comments. The error is fixed now. Thanks Adam.

OK, this was a bit tricky and I found no examples about it, so I thought to blog it. I’ll just show a quick example how to implement Zend_Captcha into a Zend_Form, may be useful for someone. There are several CAPTCHA types in ZF, like the Image, Figlet and Dumb. I use Image.

First of all, we’ll use sessions, so we need to change the bootstrap file a little:

// Put this line somewhere after the Zend_Loader::registerAutoload(); line

We need to start the session to use it, putting it close to the top will assure that there will be no “Headers already sent by…” errors caused by a wrongly placed session start.

Next we need a folder which has a 777 permission on it (Windows users, you can skip this… Or start using GNU/Linux) where we will put our captcha images for a while… This folder must be in the public folder somewhere. So create one.

How does this work? When a captcha is generated, it generates a unique ID (e.g. 539e517b0c0f4e32ef634dae92f07f77) and the word on the image. That unique ID is used for the file name of the image and for the session namespace (the namespace is like: Zend_Form_Captcha_uniqueId), so it knows which image belongs to which session. Also, the generated word is placed inside it’s own session. That ID is placed on the form in a hidden field, so when the submission is received, we can access the ID and recreate the correct session namespace and access the data in it: the word on the image.

Awesome. Now, to the fun part. I use the Zend_Form_Element_Captcha class, so no additional fooling around is needed to put the captcha in the form. Here’s the code:

public function indexAction()
// Our form object...
$form = new Zend_Form();
// And here's our captcha object...
$captcha = new Zend_Form_Element_Captcha(
        'captcha', // This is the name of the input field
        array('label' => 'Write the chars to the field',
        'captcha' => array( // Here comes the magic...
        // First the type...
        'captcha' => 'Image',
        // Length of the word...
        'wordLen' => 6,
        // Captcha timeout, 5 mins
        'timeout' => 300,
        // What font to use...
        'font' => '/path/to/font/FontName.ttf',
        // Where to put the image
        'imgDir' => '/var/www/project/public/captcha/',
        // URL to the images
        // This was bogus, here's how it should be... Sorry again :S
        'imgUrl' => '',
// Add the captcha element to the form...
        // Add the captcha to the form...
// Pass the form to the view...
$this->view->form = $form;

On the other side, it goes something like this:

public function captchaAction()
  $request = $this->getRequest();
  // Get out from the $_POST array the captcha part...
  $captcha = $request->getPost('captcha');
  // Actually it's an array, so both the ID and the submitted word
  // is in it with the corresponding keys
  // So here's the ID...
  $captchaId = $captcha['id'];
  // And here's the user submitted word...
  $captchaInput = $captcha['input'];
  // We are accessing the session with the corresponding namespace
  // Try overwriting this, hah!
  $captchaSession = new Zend_Session_Namespace('Zend_Form_Captcha_'.$captchaId);
  // To access what's inside the session, we need the Iterator
  // So we get one...
  $captchaIterator = $captchaSession->getIterator();
  // And here's the correct word which is on the image...

  $captchaWord = $captchaIterator['word']
  // Now just compare them...
  if($captchaInput == $captchaWord)
  // OK
  // NOK

Easy, ain’t it?

Happy hacking :)

Tip: Using a monospace or a serif font for the words on the image (like FreeMono.ttf found by default on Ubuntu), makes the word quite unreadable — with the FreeMono.ttf about 8 out of 10 is UNreadable — so use a sans-serif font.

Starting with Zend Framework - part 2

published on October 20, 2008.

This post is the second part of my introductory text on Zend Framework, Starting with Zend Framework. This time I cover the basics about controllers, actions, view scripts and view helpers. On request routing and the Front Controller I will write one (or more) big post(s), so this part won’t be explained now. I will also skip explaining the models; they deserve their own post :)

If anyone is into writing a guest-post on models, let me know!

The Controllers

The Controllers are the heart of every MVC based application. They control the execution of the application, what to do with the data, what to show the user, what to write to the database, etc. The Controllers that you will write all the time, are called Action Controllers. These Controllers subclass the Zend_Controller_Action abstract class. Every application module must have a default Controller, which will be accessed if no specific Controller is requested. The default name for this default Controller is Index. Examples of the IndexController and FooController:


// The IndexController class must be placed in the controllers folder
// and saved as IndexController.php
class IndexController extends Zend_Controller_Action
    public function init()

    public function indexAction()

// The FooController class must be placed in the controllers folder
// and saved as FooController.php
class FooController extends Zend_Controller_Action
    public function init()

    public function indexAction()

    public function barAction()

    public function someRandomFunctionDoingSomeFunkyStuff()

The Controllers must contain at least the indexAction() function; the others are arbitrary. I always have an init() function, in which I setup the cache object, call up the models, etc. Controller names that are not in the “default” module, must be prefixed with the Title-cased name of the module and an underscore:


// An example of the IndexController in the
// dummy module
// The file name remains IndexController.php!!!
class Dummy_IndexController extends Zend_Controller_Action

// An example of the FooController in the
// dummy module
// The file name remains FooController.php!!!
class Dummy_FooController extends Zend_Controller_Action

The actions

Actions are methods of the Controller class. Use them to do some specific task: show users, list news, insert to database (the actual INSERT SQL statement should be in the model), etc. As stated before, every Controller must have an index action — this one is called if no specific action is requested. By default the view object is instantiated, so if you don’t turn it off, you must create a view script with the same name as the action (without the “Action” word) in the views/scripts/foo/ folder.

Assigning variables to the view scripts is simple:

public function indexAction()
    $this->view->someVariable = "some value...";

The view scripts

View scripts are, well, for viewing. This is the only place where you should have statements like echo and print. The default templating engine is PHP itself, but it’s possible to change it to something like Smarty. I leave PHP; it has everything for templating, so why would I change it? The default file extension for view scripts is “phtml” — but as with everything, this can also be changed :)

Getting variables that are assigned from the action:

// Output: some value...
<?= this->someVariable ?>

The view helpers

The view helpers are simple classes that help in view scripts with things like formatting dates, creating links, etc. Here’s an example view helper that I use to show dates in “Serbian” format:

File name: views/helpers/SrDateFormat.php
* View helper for returning dates in Serbian format
class Zend_View_Helper_SrDateFormat
    public function srDateFormat($dateToFormat)
        return date('d.m.Y.', strtotime($dateToFormat));

Usage is quite simple:

// somewhere in some view script...
<?= $this->srDateFormat($someDateToShow); ?>

Bringing it all together

Just for an overview, here is an example of a Foo Controller in the Dummy module with index and bar actions and their view scripts.

// File name: application/dummy/controllers/FooController.php
class Dummy_FooController extends Zend_Controller_Action
    public function indexAction()
        $this->view->sayHello = "Hi there!";

    public function barAction()
        $this->view->sayHelloAgain = "Hi here :)";

And the view scripts:

<!-- File name: application/dummy/views/scripts/foo/index.phtml -->
<h1>Saying hello</h1>
<?= $this->sayHello ?>

<!-- File name: application/dummy/views/scripts/foo/bar.phtml -->
<h1>Saying hello again</h1>
<?= $this->sayHelloAgain ?>

So if you direct your browser to “” or to “” you should get the “Saying hello” or the “Saying hello again” page…

This would be my introductory text to Zend Framework. Hope it’s not confusing and is easy to follow. I just want to help newcomers to ZF help settling in easily :) For a tutorial application with ZF, I recommend Rob Allen’s Zend Framework tutorial.

In the coming days/weeks I’ll write a detailed post about the Front Controller, so if you wish, grab the feed or subscribe by E-mail to stay tuned.


Optimizing MySQL and a Zend_Db_Profiler example

published on October 13, 2008.

Last night I came across on a post on TechFounder, about using Zend_Db_Profiler and a good example with real data on optimizing MySQL queries. For “geeks” who SQL speak fluently this will probably be no new stuff, but for great number of web developers (me included!) this will probably come in handy.


Starting with Zend Framework

published on October 07, 2008.

Zend Framework is a big & heavy object-oriented framework for PHP. I started working with ZF a couple of months ago, I liked it’s documention (it’s very well documented) and decided to stick with this framework. Here is the latest version of the framework — at the time of writing v1.6.1.

It supports the MVC pattern, which helps separating business logic from viewing logic. It supports a great number of API’s, such as Delicious API, Flickr API, Yahoo API, Akismet API and many more.

The advantages of using a framework is that it is enforcing the developer to write code using a coding standard, it is well documented and well supported, and it is a lot easier to work in a 2+ person team using a framework. If you are a one—man team, someday you may want to add more developers to your projects; the process of their settling in will be very comfortable if you are using a framework.

Choose yourself a framework that best suits your needs, or write your own (be sure to make good documentation, also!). To be honest, I wasn’t looking at other frameworks, just ZF, but I knew right away that it is good for me. Prior to this post I did a little research on other frameworks, and I’m still sure that I made the right choice by choosing ZF.

You can read a bit more about ZF in general on the overview page.

How does it work?

Before anything, we should take a look how does the ZF work, when used in the MVC manner. ZF has a thingy, called Front Controller. When a user is accessing a web page, the Front Controller is called: it’s determining what should be done with the input and which further objects should be instantiated and methods called, and in what order.

E.g., if one makes a page request like:, first, the Front Controller is called. The Front Controller sets up the environment, loads up some files and classes, etc., then it calls a controller called “News” and an action called “Last” which is to be found inside the “News” controller. If it fails to find the “News” controller or the “Last” action, than it can show the user some error page, or to print out the error itself, depending how it is set up. If everything is OK, then it shows the user the content…

This explanation is very basic, as I intend to dedicate one big post to the Front Controller itself, going deep into details…

Some terms explained

Bootstrap file: all page requests are routed through this file, the Front Controller object is created here.

A module is a part of an application which has it’s own controllers, actions, view scripts, models, configuration files. For example, a page can have a default module and a blog module, where each module has its own Index Controller, Administrator Controller, and have its own unique controllers, like a Comments Controller for the blog module.

A controller is a class which has its own actions and can have its own functions. It controls the data received from the user or from the database, and decides what to do with it. The controller is responsible for one set of things, e.g. a News Controller would list latest news, list news from a particular source, show the archive, etc.

An action is a function inside a controller, which is responsible for doing some action, e.g. action for showing news.

A model receives data from the Controller, and sends data to the Controller. Database related stuff — selecting, inserting, updating, deleting — should be only in the model. Filtering data that is to be inserted into the database should be done in the Controller, not in the model.

A view script is responsible to show the data received from the Controller to the user.

A view helper script is to help to do some automating in the view scripts, like formatting dates, generating form elements, etc.

Just for the record, in further examples, “Dummy” will be referring to a module, “Foo” will be referring to a controller inside the “Dummy” module and “Bar” will be referring to an action inside the “Foo” controller.

Basic file structure

Here’s an example of a file structure for a ZF based application — after the # sign are comments:

|  |--Zend/ # Zend core
|--application/ # Core of our application
|   |--default/ # The Default module
|       |--config/ # Some configuration files
|          |--config.ini
|       |--controllers/ # Controllers go here
|          |--IndexController.php
|          |--FooController.php
|       |--models/ # Models...
|          |--ModelName.php
|       |--views/ # View related stuff...
|          |--helpers/
|          |--scripts/
|             |--index/ # View files for the Index Controller
|               |--index.phtml # For the default index action
|             |--foo/ # View files for the Foo Controller
|               |--index.phtml # For the default index action
|               |--bar.phtml # For a bar action in the Foo Controller
|             |--layout.phtml # For layout
|   |--dummy/ # A Dummy module...
|       |--config/
|          |--config.ini
|       |--controllers/
|          |--IndexController.php
|          |--FooController.php
|       |--models/
|       |--views/
|          |--helpers/
|          |--scripts/
|             |--index/
|               |--index.phtml
|             |--foo/
|               |--index.phtml
|               |--bar.phtml

With this file structure, should point to the public folder; this way, the application or the library can not be accessed through the browser, which improves security of the application.

The .htaccess file

The .htaccess file’s responsibility is to route requests to existing resources (existing symlinks, non-empty files, or non-empty directories) accordingly, and all other requests to the front controller. Example:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule .* index.php

The bootstrap file

The biggest problem is setting up correctly the bootstrap file. Here’s an example of my bootstrap file, I use it on several projects, never had any problems :)

* This is a general bootstrap file, change it to fit your needs
* Pay attention to the paths
ini_set('display_errors',1); // set this to 0 on live version

// This is my timezone, change it to yours
// See timezones here:

* We need to set some include paths
* To the library
* And to the models
* And add it to the current include path
set_include_path('.' . PATH_SEPARATOR . '../library' .
					   PATH_SEPARATOR . '../application/default/models' .
                       PATH_SEPARATOR . '../application/dummy/models' .
					   PATH_SEPARATOR . get_include_path());


* This little fella loads up a class when needed
* So we don't need to bother with including class files

* This config part is needed only when you
* store stuff for db connections in a .ini file
* I do it this way all the time, so it's a part of my general bootstrap
$config = new Zend_Config_Ini('../application/default/config/db_config.ini', 'offline');
$registry = Zend_Registry::getInstance();

// Only needed if you plan to use layouts in your app

* Get an instance of the Front Controller
* Tell him where to look for controllers
* And off we go!
$frontcontroller = Zend_Controller_Front::getInstance();
        'default'   =>  '../application/default/controllers',
        'dummy'       =>  '../application/dummy/controllers'
$frontcontroller->dispatch(); // GO!!!

This kind of bootstrap file should be enough in most cases; it is for me.

This post is starting to get out of control, so I’ll stop here for now. Next time I’ll show some basic stuff with controllers, actions, views etc. Until then be sure to get familiar with the coding standard, especially with the naming conventions.

Hope that this text isn’t too confusing. I tried to keep it simple and explain all that is needed for starting with Zend Framework.

Any thoughts on ZF, or frameworks in general? Do you use any?

Robert Basic

Robert Basic

Software developer making web applications better.

Let's work together!

I would like to help you make your web application better.

Robert Basic © 2008 — 2020
Get the feed