Wouldn’t it be nice if you’d had something like this:

Well, there are two things you can do.  The first is to vote on ZF-9509 and ZF-9508.  But until the documentation is fixed, you can download my Greasemonkey script that gives you a page TOC right now:

[Download id not defined]

Hope you enjoy!

The book is structured in two parts.  The first two chapters cover the basic setup of the Zend Framework (ZF) and, more specifically, a look at its Model-View-Controller (MVC) implementation.  Almost all of the book from there on out focuses on building a real-world ecommerce application using ZF.  I tend to be a learning-by-doing type of person, which I think tends to be true of many programmers, so I think this is a pretty good way to lay out a book.

Much of the book focuses on Models, and how to use various ZF components to implement your domain logic.  Most people agree nowadays that you should have fat models and skinny controllers (in that your controllers should really just have enough code to facilitate your models doing the work), and Keith Pope’s focus on models really hits this home in the book.  The topics of user accounts, the shopping cart and the catalog are all addressed in this light, while still bringing up topics like forms, controllers, views, action helpers, etc.

In general, the book focuses on best practices, which I think is really important for new ZF developers.  Because one of the guiding principals of the Zend Framework is that it gives you freedom to implement things however you like and use only the components you want, it can be hard for people just getting started to get a sense of how they should use certain components, and particularly how everything falls together in a “typical” MVC application.   Following along with the development of the storefront application in this book is a great way to see how those components often are used together.

That said, there are ways in which the code in this book is outdated or less-than-ideal.  As with anything that moves as fast as the Zend Framework has been moving, it’s hard to keep up with the latest tricks and best practices (and in some places it feels like they skipped on editing to try to publish the book before it got too outdated—there are plenty of minor code inconsistencies and typos throughout).  This book is a good place to get started, but keep in mind that the Zend Framework is already at 1.10, with 2.0 on the horizon, so anything that’s not the Zend Framework Official Documentation is in danger of being out of date at any moment.

Also, keep in mind that there’s already a lot of good information out there, so if you don’t mind finding it yourself, you might not need a book.  In fact, I found that most of the code in the authorization chapter was almost a direct copy of Matthew Weier O’Phinney’s blog post on Applying ACL’s to Models.  If you read blogs like Matthew’s (who is the project lead for ZF, and a fantastic resource) and spend time on #zftalk you can figure most things out on your own (Ben Scholzen’s demo application is another good starting point).  The information may be a little scattered, but it’s out there.

In the end, I think that this book would be a really helpful resource to someone who’s just getting started with MVC architecture and other design patterns in PHP.  It also is a good way to see most of the Zend Framework best practices put to use in one place.  On the other hand, if you want the latest information available and are willing to work for it, everything you need is probably online and free.

Some resources that might be helpful to new ZF developers:

• Zend DevZone
• Questions tagged w/ Zend Framework on Stack Overflow
• #zftalk
• Zend Framework in Action Blog
• Matthew Weier O’Phinney’s Blog
• Ryan Mauger’s Blog
• Ben Scholzen’s Blog

source path/to/zf.bash

Next time you load the terminal, you can type “zf c” and hit TAB twice to see a list of available commands (change, configure and create” or type “zf cr” and hit TAB to have “create” automatically inserted for you.  The script works for both action names and provider names (but not for anything past that).  Eventually I want the script to dynamically load the available commands (so that it works with custom providers and future versions of ZF without updates) but I couldn’t get that working for this version so I just hard coded them.

There’s also a version that completes commands from the Galahad Framework Extension if you’re testing that out…

Enjoy!

• Authorize access to a model’s method
• Authorize access to a controller action
• Authorize access to an arbitrary “permission”

In general I find it’s best to keep authorization within the domain (querying the ACL within my models when they’re accessed) as this provides the most consistent behavior.  For example, if I eventually add a REST API to my application I don’t have to duplicate all my authorization logic in the new REST controllers.  When the application calls something like Default_Model_Post::save() it either saves or throws an ACL exception, no matter where it was called from.  This is great in that it saves me from having to duplicate code and keeps my system more secure.

On the other hand, there are times when it’s just a lot easier to handle authorization in the controller.  For example, if guests should never access my “Admin” module, it doesn’t make sense to ever let them access /admin/ URLs.  Also, if you’re using Zend_Navigation, having ACL resources that match controller actions lets you utilize its ACL integration.

If you’re ever going to mix these two techniques, you’ll eventually bump into the case where a model and a controller share the same name.  What if you need to set permissions on a “user” controller and different permissions on a “user” model?  This is where namespacing comes into play.  As suggested by the Zend Framework manual, I always name my controller action resources in the format mvc:module.controller.action.  I name my model resources similarly, in the format model:module.modelName.methodName.  In both theses cases, “mvc” and “model” are the namespace, and everything following the colon is the actual resource name.  Now I can refer to my “admin” module as mvc:admin and the models within my admin module as model:admin.

This is where things get interesting.  If you set up your ACL chains correctly, you can set permissions on whole modules or models and have those rules cascade to their child controllers or methods.  For example, say you set up your ACL as follows:

$acl = new Zend_Acl();
$acl->addResource('mvc:');
$acl->addResource('mvc:admin', 'mvc:');
$acl->addResource('mvc:admin.user', 'mvc:admin');
$acl->addResource('mvc:admin.user.create', 'mvc:admin.user');

$acl->addRole('guest');
$acl->addRole('admin', 'guest');

$acl->deny();
$acl->allow('admin', 'mvc:admin');

Now if a user with the role “admin” tries to access the resource “mvc:admin.user.create” (http://basename/admin/user/create) they will be allowed, but a user with the role “guest” will not.  Using this technique gives you as much granularity as you need in your ACL, but at the same time lets you set broad permissions where appropriate.

This is where Galahad_Acl comes into play.  Setting up all these resources can be tedious, as is checking permissions in each controller.  Galahad_Acl in conjunction with Galahad_Model_Entity and Galahad_Controller_Plugin_Acl automate everything but the actual permissions that are specific to your application.

By default, whenever Galahad_Acl has a role added to it in the format “namespace:resource.subResourse” (etc) it automatically adds the resources up the chain.  For example, if I add “mvc:default.index.index” to a Galahad_Acl object, it would add the following resources to the ACL:

• mvc:
• mvc:default (parent = “mvc:”)
• mvc:default.index (parent = “mvc:default”)
• mvc:default.index.index (parent = “mvc:default.index”)

Galahad_Controller_Plugin_Acl takes this a step further by automatically adding any controller action that’s dispatched to the ACL and then checking against the ACL.  This means that with the following ACL:

$acl = new Galahad_Acl();
$acl->addRole('guest');
$acl->addRole('staff', 'guest');
$acl->addRole('admin', 'staff');
$acl->addResource('mvc:blog.entry.view');
$acl->deny();
$acl->allow('admin', 'mvc:');
$acl->allow('staff', 'mvc:blog');
$acl->allow('guest', 'mvc:blog.entry.view');

The following would be true:

• Role “admin” would be allowed access to any URL (“admin” is allowed access to “mvc:”)
• Role “staff” would be allowed access to /blog/entry/edit even though permissions weren’t explicitly set for the resource “mvc:blog.entry.edit” (because “staff” is allowed to access “mvc:blog”)
• Role “guest” would be allowed to view /blog/entry/view but no other portion of the blog (“guest” is allowed access to the specific resource “mvc:blog.entry.view”)

Galahad_Model_Entity works similarly.  By default each entity adds itself to the ACL in the format “model:module.modelName” so that the model Default_Model_User has the resource ID “model:default.user”.  Each model has a method called _initAcl which lets you manage permissions on a per-model basis.  This is better demonstrated in code:

class Default_Model_Post extends Galahad_Model_Entity
{
    protected function _initAcl($acl)
    {
        // Deny permissions to anything on this model unless explicitly allowed
        // We don't have to add "model:default.post" because Galahad_Model_Entity
        // automatically does that for us
        $acl->deny(null, $this);

        // Allow guests to fetch the content of posts
        $acl->allow('guest', $this, 'fetch')

        // Allow admins to save changes to posts
        $acl->allow('admin', $this, 'save')
    }

    public function save()
    {
        if (!$this->getAcl()->isAllowed($this->getRole(), $this, 'save')) {
            throw new Galahad_Acl_Exception('Current user is not allowed to save posts');
        }

        $dataMapper = $this->getDataMapper();
        return $dataMapper->save($this);
    }
}

So, as you can see, the model denies access to itself unless explicitly allowed, and then allows access to certain methods for certain roles.

All three of these classes are in their early stages of development, but I’d love some feedback on the ideas/suggestions on how to make them better.

Check out the code on GitHub:

• Galahad_Acl
• Galahad_Controller_Plugin_Acl
• Galahad_Model_Entity

Also, for more information about the Galahad_Model system, check out my previous post on modeling in the Zend Framework.

Recently I was building a form that contained a URL field, and after browsing the Zend_Validate docs, I was surprised not to find a Zend_Validate_Uri component.  Luckily, Zend_Uri already validates URIs, so it was just a matter of writing a wrapper that followed the Zend_Validate APIs.  Basic usage:

$validator = new Galahad_Validate_Uri();
$validator->isValid('http://www.google.com/');

Obviously this would be much more useful when combined with Zend_Form or some more extensive validation chains, but you get the point.

Grab Galahad_Validate_Uri from GitHub.

The second issue I often deal with is people forgetting (or not knowing) to include http:// in the URLs that they submit.  Rather than solve this at the controller-level, I decided this was a common enough problem to build a Zend_Filter component for.  Basic usage:

$filter = new Galahad_Filter_PrependHttp(array(
    'allowedSchemes' => array('http://', 'https://', 'mailto:'),
    'checkUri' => true,
));
echo $filter->filter('google.com'); // Prints 'http://google.com'

This filter takes any string and prepends “http://” to it if it doesn’t already contain an allowed scheme (more on that below).  By default it allows “http://”, “https://” and “mailto:” schemes, but you could set this to anything (say you want to allow “itms://” [iTunes] links) by setting the ‘allowedSchemes’ option.  It also (optionally) checks if the resulting URI is valid, and only applies the filter if it is (effectively only prepending “http://” to otherwise valid URIs).  Remember, though, that “http://something” is technically a valid URI, so that will be accepted.  In the future I hope to add additional options to limit to URLs that follow certain standards.

Grab Galahad_Filter_PrependHttp from GitHub.

Update: I’ve submitted Zend_Filter_PrependHttp to the Zend Framework wiki for comments.  Check it out and let me know if you think there’s anything I should change (I’ve posted a few ideas already).

The validator and filter work well together with Zend_Form to create URL form elements:

$this->addElement('text', 'my_url', array(
    'label' => 'URL:',
    'filters' => array('StringTrim', 'StringToLower', new Galahad_Filter_PrependHttp()),
    'validators' => array(new Galahad_Validate_Uri()),
));

The form element generated by that code will produce fairly normalized, valid URIs.

About a month ago I posted some ideas about PHP modeling in the Zend Framework and requested feedback. After a month of on-and-off discussions through this website and #zftalk I decided to sit down and implement things a little more.

I now have some working base classes that can be found on GitHub. Right now I’m still thinking things out, so there’s no guarantee that’s the structure I’m going to finish with, but it’s what I’m playing with right now. So far I’ve dropped the DAO interface and the Galahad_Service parent class all together (since both are going to be pretty unique to your application). What’s left is mostly the Entity class and the DataMapper class (as well as a very generic Collection class).

I’ve also started to write some tooling for my modeling system, based on Zend_Tool. Right now it’s generating the model itself, a DAO based on Zend_Db_Table and a Zend_Form (see Matthew Weier O’Phinney’s post about using forms in your models for my reasoning there). It doesn’t generate the DataMapper yet, but that’s just a matter of writing the code…

Again, I’d love some feedback on the direction this is going. Check out the video below and then let me know. Comment below, email me at *****@cmorrell.com or get in touch on Twitter: @inxilpro.

[View full size, or watch below]

Follow-up Video (demo of a lot more code):

$jan1 = new Zend_Date('1.1.2009', Zend_Date::DATES);
echo "\nJanuary first: ", $jan1->toString();

$christmas = new Zend_Date('25.12.2009', Zend_Date::DATES);
echo "\nChristmas is on: ", $christmas->toString();

$diff = $christmas->sub($jan1);
echo "\nNumber of days: ", $diff / 60 / 60 / 24;

Zend Framework’s project lead, Matthew Weier O’Phinney, has a lot of great thoughts about Modeling that I’ve been trying to stick to. In implementing those ideas, I’ve started thinking out some base classes to build my Models on top of. Obviously these classes won’t work for everyone. But they should work for a lot of “typical” web applications.

That said, here are some notes that I’ve been putting together. I’m posting them now (very early) in hopes that I get some feedback.

The 6 Classes

Galahad_Model

This is the base class that all my others extend. It is there mostly to provide some helper functionality that all my other classes use (mostly for guessing class names based on a naming convention—more on that later).

Galahad_Model_Entity

The Entity is the base for all things. For example, a User would extend the Entity class. The Galahad_Model_Entity class has some basic methods for getting other objects. I haven’t thought this entirely through yet, but an example would be the Entity’s “Parent” Service (see below) or maybe a Form associated with that model or something similar.

Galahad_Model_Collection

The Collection class is just a wrapper for an array of Entities. I like this because it allows for type hinting/etc. This is pretty much a generic wrapper for an array that implements Iterator and Countable. I can’t think of much more that it needs.

Galahad_Model_Service

This probably doesn’t belong as part of the “Model”—I need to think that out. The Service Layer is where your application logic happens that’s not strictly part of a particular Model (for example, an interaction between two Models). An example might be authentication. The service layer will often map pretty closely to a public API (although obviously there will be things that your application can do that shouldn’t be exposed to the public).

Galahad_Model_DataMapper

The DataMapper maps your Entity to the appropriate DAO (see below) and makes sure the DAO gets the data it’s expecting. The way I think about this is that the Data Mapper expects an Entity as its input, but passes an array to the DAO.

Galahad_Model_Dao

The Data Access Object (DAO) is what takes the actual data in your entity and persists it. The most common DAO is going to be a database, but a web service could be a DAO as could a filesystem or any other method of persisting data. The DAO is going to have similar methods as the DataMapper, but it expects just the data—nothing else (that’s why you need the DataMapper to fetch and process the data in your Entity). An easy way to show this is in code:

class Default_Model_DataMapper_User
  extends Galahad_Model_DataMapper
{
    public function save(User $user)
    {
        $dao = $this->_getDao();
        $dao->save(array(
            'name' => $user->getName(),
            'email' => $user->getEmail(),
            'date_modified' => time(),
        ));
    }
}
class Default_Model_Dao_DbTable_User
  extends Zend_Db_Table_Abstract
  implements Galahad_Model_Dao_Interface
{
    protected $_name = 'user';

    public function save(Array $data)
    {
        $this->insert($data);
    }
}

Notes

I’m going to reiterate one more time that this is a very early concept and that I’m looking for feedback. It could be that I’m thinking about things completely backwards and it all needs to be thrown away. At this point I certainly don’t recommend people running too far with these ideas until they’ve been discussed/thought out a little more.

About the Galahad_Model base class—since all the different pieces of your model will likely follow the same naming conventions, the Galahad_Model class provides some helper functionality to guess the name of classes. For example, inside of Default_Model_DataMapper_User you’ll probably need to get an instance of Default_Model_Dao_DbTable_User. So Galahad_Model_DataMapper provides a nice getDao() method to do this for you. If you’ve set the DAO, it uses that, but if you didn’t, it assumes you want a DbTable, guesses the name for you based on the DataMapper’s class name (so that if you choose My_Model_DataMapper_Person it’ll know to return a My_Model_Dao_DbTable_Person) and instantiates it for you.

Thoughts?

What do you think? Does this make any sense? Or am I trying to make a simple thing more complicated than it needs to be? I think a lot of this would make more sense in code, so maybe I’ll try to get what I have started cleaned up a little and attach it to this post. In the meantime, I’d love feedback (in the comments below, or to @inxilpro.

First, download the Plugin

Put the following class in a library/Galahad/Controller/Plugin/Modularlayout.php file (you’ll probably have to create all those directories and the file).

<?php
/**
* This file is part of the Galahad Framework Extension.
*
* The Galahad Framework Extension is free software: you can redistribute
* it and/or modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation, either version 3 of the
* License, or (at your option) any later version.
*
* The Galahad Framework Extension is distributed in the hope that it will
* be useful, but WITHOUT ANY WARRANTY; without even the implied warranty
* of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
* General Public License for more details.
*
* @category  Galahad
* @package   Galahad
* @copyright Copyright (c) 2009 Chris Morrell <http://cmorrell.com>
* @license   GPL <http://www.gnu.org/licenses/>
* @version   0.2
*/

/**
* Use separate layout per module
*
* @category   Galahad
* @package    Galahad
* @copyright  Copyright (c) 2009 Chris Morrell <http://cmorrell.com>
* @license    GPL <http://www.gnu.org/licenses/>
*/
class Galahad_Controller_Plugin_Modularlayout extends Zend_Controller_Plugin_Abstract
{
     public function routeShutdown(Zend_Controller_Request_Abstract $request)
     {
          Zend_Layout::getMvcInstance()->setLayout($request->getModuleName());
     }
}

Next, add the Galahad namespace

Update your Bootstrap.php file’s autoloader initialization method (if you don’t have one, add one):

protected function _initAutoloaders()
{
	$this->getApplication()->setAutoloaderNamespaces(array('Galahad_'));
	return $this;
}

Please note: You might need to have other namespaces in there, like My_ or App_ or Default_.

Next, add the Plugin

Update your Bootstrap.php file’s plugin initialization method (if you don’t have one, add one):

protected function _initPlugins()
{
	$this->bootstrap('autoloaders');
	$this->bootstrap('frontController');

	$plugin = new Galahad_Controller_Plugin_Modularlayout();
        $this->frontController->registerPlugin($plugin);
}

And you’re set!

Just make sure you have a layout file in your layouts directory for each module (modulename.phtml).

CSS IDE Wishlist

1. Order auto-complete based on usage, not alphabet
   I’m sick of typing “d” and getting “direction” when I clearly have never used the CSS direction property in my entire life.  Clearly I mean display.  I use the display property all the $*(#ing time, and yet every time I hit “d” what do I get?
2. Arrange properties alphabetically or by group
   I’m a little obsessive about organizing my style sheets, and as part of that I generally try to keep properties in the same general place for each rule.  For example, I try to keep positioning properties near the beginning of each declaration, presentational properties after that, and anything else last.  But of course the order gets messed up.  Wouldn’t it be really cool if you could just press a button and have your IDE reorder all your declarations so they follow some set of rules?  Maybe a little overboard, but it would be really useful.

HTML IDE Wishlist

1. Pattern recognition
   OK, how many times have I populated a list with the following code:

   <li><a href="#">Something</a></li>
   <li><a href="#">Something Else</a></li>

   Wouldn’t it be really cool if on the third list item an auto-complete drop down popped up offering:

   <li><a href="#">|</a></li>

   Or something similar

2. Lorem ipsum autocomplete
   I know some IDEs have a lorem ipsum generator built in, but wouldn’t it be cool if when you started typing lorem ips it would offer something like:

• Lorem ipsum (1 paragraph)
• Lorem ipsum (2+ paragraphs…) — would pop up a generator dialog
• Lorem ipsum (list of 10 elements)
• Lorem ipsum (list of elements…) — would pop up  a generator dialog

Even cooler would be if it adjusted the suggestions from context—so if you were in a list it would offer a list first, etc.