Rob Allen's DevNotes

Following on from the discussion on the FlashMessenger action helper, I thought I'd also cover another supplied helper: Redirector.

Redirector does what it says on the tin and redirects the user to another page. I mostly use this when coming back from filling a form in, so that the user is then redirected to another page. In admin systems, this is usually a list page. On front end websites, this is usually a thank you page. Though for log-in forms, I tend to try and return the user to where they were going!

It's used in a controller action method like this:

$urlOptions = array('controller'=>'index', 'action'=>'index');
$this->_helper->redirector->gotoRoute($urlOptions);

gotoRoute() takes the same set of parameters are the url() view helper which is not a surprise as they both proxy through to the Front Controller's router object. It's handy though as one you know one, you know the other :)

If you are using the default route, then you can use gotoSimple(). For example to redirect to the news controller's list action, you would do:

$this->_helper->redirector->gotoSimple('list', 'news');

The gotoSimple() method signature is:

gotoSimple($action, $controller = null, $module = null, array $params = array());

As you can see, it provides defaults for the controller and module and params parameters so you only need to set them if you need to. This works well for admin system as I tend to be redirecting within the same controller (from the edit or delete action to index, usually).

You can also use the Redirector with an absolute URL, by using the gotoUrl() method:

$url = 'http://www.akrabat.com';
$this->_helper->redirector->gotoUrl($url);

I tend to use this one much less frequently - so infrequently, that I can't think of a use-case off the top of my head :)

By default, Redirector sets a 302 status code, however you can also set a 301 if you want to:

$this->_helpers->redirector->setCode(301);

There are a few other options that can be set like setExit() and setUseAbsoluteUri(), but to be honest, I don't think I've ever used them!

I find that I use Redirector fairly frequently as its gotoRoute() uses the same parameters as url() which makes it easy to remember how to use it. Like url(), it also benefits from remembering which route was used to get you to the current page and reuses that when creating the next one which is handy.

I've talked about Zend Framework's action helpers before, but haven't covered any of the action helpers that are supplied with Zend Framework.

FlashMessenger is a helper that allows you to store messages between requests. The most common use I have for it is for a "saved" message after doing an edit of an item that then redirects back to a list.

This is how it's used:

Storing a message

Storing to the FlashMessenger is easy. This is my typical usage within an action controller:

$this->_helper->flashMessenger->addMessage('Task saved');
$this->_helper->redirector('index');

This code adds the message "Task saved" to the FlashMessenger and then redirects the user the index action, which in this case is a list of tasks. As should be obvious from the name of the method, you can add multiple messages and they will all be stored for retrieval after the next redirect.

The FlashMessenger will store the message that you've added for one hop, or number of requests. This means that the message will be available for retrieval on the next request, but unavailable on the request afterwards. This is very useful and it means that if someone refreshes the task list by hitting F5, then the "Task saved" message does not reappear.

Retrieving the stored messages

Retrieving the stored messages is similarly simple:

$this->view->messages = $this->_helper->flashMessenger->getMessages();

This will create an array of messages in your view object which you can then loop over in your view script:

<?php if (count($this->messages)) : ?>
<ul id="messages">
<?php foreach ($this->messages as $message) : ?>
    <li><?php echo $this->escape($message); ?></li>
<?php endforeach; ?>
</ul>
<?php endif; ?>

and that's all there is to the FlashMessenger.

After too many months of neglect, I have completely rewritten my Zend_Auth tutorial so that it is compatible with Zend Framework 1.10!

As an experiment, I have written it directly in HTML, rather than PDF as before and cover the login form along with the login controller code required to authenticate a user using a database table. For good measure, I've included logging out and a view helper to show how to access the logged in user's details.

The full source code is also available, if you don't want to type it in :)

I hope you find it useful.

I've updated Akrabat_Db_Schema_Manager so that it now supports table prefixes.

It uses the application.ini key of resources.db.table_prefix as I couldn't think of a better one :) and then uses that for the schema_version table's name and also makes it available in your change objects.

For example, if application.ini contains resources.db.table_prefix = "myapp", then the manager will create the table myapp_schema_version to store the current version of the schema. In your change classes, you can then do this:

001-Users.php:

 class Users extends Akrabat_Db_Schema_AbstractChange 
 {
     function up()
     {
         $tableName = $this->_tablePrefix . 'users';
         $sql = "
             CREATE TABLE IF NOT EXISTS $tableName (
               id int(11) NOT NULL AUTO_INCREMENT,
               username varchar(50) NOT NULL,
               password varchar(75) NOT NULL,
               role varchar(200) NOT NULL DEFAULT 'user',
               PRIMARY KEY (id)
             ) ENGINE=InnoDB DEFAULT CHARSET=utf8;";
         $this->_db->query($sql);

         $data = array();
         $data['username'] = 'admin';
         $data['password'] = sha1('password');
         $data['role'] = 'admin';
         $this->_db->insert($tableName, $data);
     }

     function down()
     {
         $tableName = $this->_tablePrefix . 'users';
         $sql= "DROP TABLE IF EXISTS $tableName";
         $this->_db->query($sql);
     }

 }

which will create a table called myapp_users. Note that you are responsible for using the prefix property as the change classes cannot enforce what you do within the up() and down() methods. It also follows that you'll have to ensure that your models also use the correct prefix.

I have also made a change to the provider (Akrabat_Tool_DatabaseSchemaProvider) so that it loads the correct application.ini file based on the data in the project's profile. This shouldn't affect anyone using Akrabat_Db_Schema_Manager, except that we no longer define APPLICATION_ENV and APPLICATION_PATH for you.

Enjoy!

On the ZF mailing lists, there's been a discussion on creating a community team with a follow-up by Matthew.

I was going to write up a little about it as I'm one of the volunteers on the team. However, Pádraic beat me to it and I don't think I could have written it any better, so go and read his write-up instead!

The CR Team at the moment is:

• Rob Allen (Akrabat)
• Pádraic Brady (PadraicB)
• Steven Brown
• Shaun Farrell (farrelley)
• Pieter Kokx (kokx)
• Dolf Schimmel (Freeaqingme)
• Ben Scholzen (DASPRiD)

(alphabetical order has always suited me!)

We all accept email and can be found on irc in #zftalk.dev (freenode). Most are on Twitter too. Feel free to contact any of us about anything to do with contributing to Zend Framework and we'll find someone to help you!