<form action="<?=$this->element->getAction()?>">
<?=$this->element->name->renderViewHelper()?>
</form>

In a form ViewScript, just output that directly into your viewscript!

<form action="<?=$this->form->getAction()?>">
<?=$this->form->name->renderViewHelper()?>
</form>

If you want the script to be reusable, just use the render viewhelper, as recommended in the performance guide.

I would like to argue that the proper use for the Zend ACL is actually impossible, since there is a reported bug in the code which, to my knowledge, has not been fixed.

The use case I will discuss is where you want to only authors to edit articles and only to articles authored by themselves. I think this is a fairly common case.

How does the ACL help us? The ACL allows the developer to setup access rules for arbitrary resources and arbitrary roles. The key word here is “arbitrary”, and I’ll get back to that in a moment.

My feeling is that when most people start out with the ACL, they assume that resources are controllers (or some combination of module and controller), and permissions are actions. So, for example, let’s say you had a controller called “Article” with an action called “edit”.

class ArticleController extends Zend_Controller_Action {
  public function editAction() {
     //do stuff
  }
}

So an ACL would be set up with something like this:

$acl = new Zend_Acl();
 
$acl->add(new Zend_Acl_Resource('article'));
 
$acl->addRole(new Zend_Acl_Role('author'));
 
$acl->deny();
 
$acl->allow('author', 'article', array('edit'));

This looks farely straight forward. Some place before the action is dispatched, like in a plugin, action helper or whatever you want, you would do a check against this acl.

$acl->isAllowed($role, $resource, $permission);

There are two problems with this approach, one obvious and one not so obvious.

The obvious one is that, while this may be successful in blocking regular users from editing the articles, it doesn’t block another author from editing the article.

In order to do that, we need to add in an additional assertion:

$acl->allow('author', 'article', array('edit'), new AssertionIsArticleAuthor());

The problem then becomes: in this assertion, how do you know which article it is? How do you know who the current author is? These can be very tricky questions. You might have to somehow stick the request object in there, and access the Zend_Auth singleton. While these certaintly are viable solutions, they just “smell” bad.

The other not so obvious problem is seen by taking a few steps back and looking at the whole problem from the beginning. The first question to ask is, what exactly are we trying to solve here? We want to restrict access to an article. So what did we do instead? We restricted access to a controller? What kind of sense does that make? Additionally, we are now tying in our ACL implementation to the url structure of the site. That is primarily a function presentation. If we would want to change that, it would require changing our ACL implentation. While Zend_Acl is certainly a “Zend” component, it has nothing directly to do with Zend MVC, but this approach ties us down to Zend MVC. What if we decided one day that we did not like the MVC components of ZF and wanted to move to Symfony or MVCnPHP?

Zend Framework is primarily a presentation framework. It helps in providing a clear and organized way to bring the presentation layer to the user. And that’s what it excels at. That, I believe, is the number one reason why they don’t ship with a “model” component. The model layer must be provided by yourself, and this part is probably the hardest part of the whole game. But if you keep some simple principles in mind, and keep focused, you can reapproach this whole problem in a new light.

We’ll start with our model layer. This should be fully functional without ZF. Pretend you’re writing a desktop app. Or a shell script. Whether or not the model layer should be tied to the database or separated from that as well, is a different question.

My personal approach, one which is fairly common in the Java world, is to work with Business objects, which are just “POPOs”…Plain Old PHP Classes. These business objects represent all the entities in my application…but this is a post for later. Let’s not digress too much.

In our model layer, we have two objects, an Article and an Author.

class Article {
    public $id;
    public $title;
    public $body;
 
   /**
   * @var Author
   */
   public $author;
}
 
class Author {
    public $id;
    public $name;
}

Any business logic in your app should either take place within these objects, or within other objects that act as a service layer. Your controllers should either talk to these service layer objects or to the business objects themselves.

When you retrieve data from the database, instead of keeping it around as array, put it in one of these objects. You can also use a custom Zend_Db_Row object for this to if you want to make things really simple.

Now that we’re dealing with objects, we can see that we want to restrict access to an Article object to the Author object contained within it. So our resource becomes the Article and the role is the Author. How do you define these as resources and roles? All we have to do is have our objects implement the Zend_Acl_Resource and Zend_Acl_Role interfaces! So we will modify the previous code to something like this:

class Article implements Zend_Acl_Resource_Interface {
    public $id;
    public $title;
    public $body;
 
   /**
   * @var Author
   */
 
   public $author;
 
   public function getResourceId() {
       return 'article';
  }
}
 
class Author implements Zend_Acl_Role_Interface {
    public $id;
    public $name;
 
    public function getRoleId() {
        return 'user';
   }
}

Now we write our custom assertion:

class Chintion_Acl_Assert_AssertIsArticleAuthor implements Zend_Acl_Assert_Interface
{
    public function assert(Zend_Acl $acl, Zend_Acl_Role_Interface  $author = null,
    Zend_Acl_Resource_Interface $article = null, $privilege = null)
    {
          return $this->article->author == $author;
    }
}

Now when you have your Article object, you can take your Author object (which you can either store in Zend_Auth or construct it from the data in Zend_Auth), and do a check like this:

$acl->isAllowed($author, $article);

Very nice, clean and simple.

Except…..

It won’t work. By the time the assertion gets a hold of the instance of Zend_Acl_Role_Interface, its been demoted to plain old Zend_Acl_Role. Ditto for Zend_Acl_Resource_Interface. It doesn’t have our fancy beefed up role or resource.

This I think is due to the bug report that I linked to at the beginning. Fortunately, for the moment, there’s a work around:

We have to override the method Zend_Acl::get(Zend_Acl_Resource_Interface $resource) and the method Zend_Acl_Role_Registry::get(Zend_Acl_Role_Interface $role);

To do this, you have to subclass Zend_Acl and overridde the get method as such:

public function get($resource)
{
    if ($resource instanceof Zend_Acl_Resource_Interface) {
        return $resource;
    }
    return parent::get($resource);
}

and similary for Zend_Acl_Role_Registry:

class RoleRegistry extends Zend_Acl_Role_Registry {
    public function get($role)
    {
        if ($role instanceof Zend_Acl_Role_Interface) {
            return $role;
        }
 
        return parent::get($role);
 
    }
}

and in your subclassed Zend_Acl:

$this->_roleRegistry = new RoleRegistry();