The main classes of CakePHP’s ACL implementation are named ACO and ARO, which are acronyms for the technical terms “access control object” and “access request object”. An access control object is something that gets accessed, whereas an access request object is something that wants to access an access control object.

As those acronyms are probably not that familiar to most (I heard them for the first time with the introduction of the ACL feature), you always have to perform translations when you read/hear “ACO” or “ARO”:

ACO => Access Control Object => term you are familiar with
ARO => Access Request Object => term you are familiar with

After a while you (resp. your brain) will make those translations automatically. However, at the beginning, when you try to grasp CakePHP’s ACL implementation, those translation automatisms are not there yet, which makes the understanding more difficult…

Now compare this with the names used in the Zend framework: Zend_Acl_Resource (= ACO) and Zend_Acl_Role (= ARO). At least to me those names sound quite familiar. They are very similar to the terms I would use in a discussion about authorization. And because of this familiarity, the aforementioned translation process can be omitted.

And so I think it would also make sense for CakePHP to use terms like “resource” and “role” instead of ACO and ARO to make it easier for those who want to learn how the ACL feature works.

The first approach is to copy the HtmlHelper from the core (cake/libs/view/helpers/html.php) to the helpers folder of your application (app/views/helpers). And then you can modify this file as you like. Easy. The problem of this approach is the code duplication. If something in the core HtmlHelper is changed by the developers you have to reapply the changes in your own HtmlHelper…

The second approach is to replace the HtmlHelper with your own helper that extends the HtmlHelper. For this purpose you have to create a custom view class which overrides the _loadHelpers() method of the View. It’s probably best if I do a simple example to show the idea.

First we create our own helper:

// app/views/helpers/example.php
App::import('Helper', 'Html');
class ExampleHelper extends HtmlHelper {
    public function link($title, $url = null, $htmlAttributes = array(), $confirmMessage = false, $escapeTitle = true) {
        return '<a href="http://example.com">example</a>';
    }
}

Next, we create our custom view class:

// app/views/example.php
class ExampleView extends View {
    public function &_loadHelpers(&$loaded, $helpers, $parent = null) {
        $loaded = parent::_loadHelpers($loaded, $helpers, $parent);
        $helper = 'Html';
		
        if (isset($loaded[$helper])) {
            App::import('Helper', 'Example');
            $loaded[$helper] = new ExampleHelper();
	
            // everything from here on is copied from View::_loadHelpers()
		
            $vars = array('base', 'webroot', 'here', 'params', 'action', 'data', 'themeWeb', 'plugin');
            $c = count($vars);

            for ($j = 0; $j < $c; $j++) {
                $loaded[$helper]->{$vars[$j]} = $this->{$vars[$j]};
            }

            if (!empty($this->validationErrors)) {
                $loaded[$helper]->validationErrors = $this->validationErrors;
            }

            if (is_array($loaded[$helper]->helpers) && !empty($loaded[$helper]->helpers)) {
                $loaded =& $this->_loadHelpers($loaded, $loaded[$helper]->helpers, $helper);
            }
        }
		
        return $loaded;
    }
}

You probably wonder why I override _loadHelpers() and not _loadHelper(). Well, the reason is simple, there is no _loadHelper() method in the View class. And so I have to copy the code to setup a helper from the parent method. Not very clean, I know…

The last step is to specify that we want to use the view class we created above. We can do this in the AppController with:

// app/app_controller.php
class AppController extends Controller {
    public $view = 'Example';
}

Now, all links in our views should point to example.com.

The obvious disadvantage of this approach is that it is a hack ;-) And I’m not sure whether it works to 100%. Use it on your own risk!

Personally, I would like to see the approach described by grigri (see his comment) in the core (or something similar): “It would be great if the cake helpers were really named ‘BaseHtmlHelper’ with an empty class ‘HtmlHelper’ which is loaded from the cake folder if not present in the app folder.”

With singular/plural conventions I mean the following conventions every new baker has to learn while doing his first steps with Cake:

• Table names are plural (e.g. posts, categories, request_tokens)
• Model names are singular (e.g. Post, Category, RequestToken)
• Controller names are plural and ending with “Controller” (e.g. PostsController, CategoriesController, RequestTokensController)

I follow those conventions automatically, but I have to admit I don’t see any real advantages in the distinction between singular and plural names at the moment. On the other hand, the disadvantages are they only work if you use English names (else you have to define your own rules in app/config/inflections.php), they make the learning curve steeper, and if you look at tables as objects it is not that logical to use plural names for them…

Please don’t get me wrong, I think it is a good thing to have naming conventions, but I also think the current conventions could be simplified, to something like:

• Table names are singular (e.g. post, category, request_token)
• Model names are like table names, but camel-cased (e.g. Post, Category, RequestToken)
• Controller names use the model names plus “Controller” (e.g. PostController, CategoryController, RequestTokenController)

You would get all the benefits of naming conventions without having to care whether a name has to be singular or plural. And the conventions would also work for people who prefer to use names in their native languages.

I know, those singular/plural conventions probably won’t disappear, as they are core conventions and a change would affect many Cake applications… At least I learned something about the design of conventions from this example ;-)

That’s indeed a bit illogical if you think about it. It would be more logical to define the helpers directly where they are needed, in the views.

After some experimenting and digging in the source of the View class I found a relatively clean way to accomplish that by using a custom view class.

Ok, here is what I did. First I created a custom view class called “AppView” in app/views/app.php. It contains one method to load the helpers, which is later used in the views. I also had to override the constructor to support “global” helpers (i.e. they can be used in all views). So instead of defining them in the AppController they are now defined in the $helpers array of this custom view. FormHelper, HtmlHelper, and SessionHelper do not have to be defined, they are automatically loaded by CakePHP.

// app/views/app.php
class AppView extends View {
    public $helpers = array('Navigation');
	
    public function __construct(&$controller, $register = true) {
        $globalHelpers = $this->helpers;
        parent::__construct($controller, $register);
        $this->loadHelpers(array_merge($this->helpers, $globalHelpers));
    }
	
    public function loadHelpers($helperNames) {
        $helpers = $this->_loadHelpers($this->loaded, $helperNames);

        foreach ($helpers as $helper) {
            $name = str_replace('Helper', '', get_class($helper));
            $this->$name = $helper;
        }
    }
}

To use this custom view class, I have to tell the AppController to do so by setting the $view property:

// app/app_controller.php
class AppController extends Controller {
    public $view = 'App';
    ...
}

And finally I can load and use the desired helpers in the views like:

<?php 
$this->loadHelpers(array('CamelCase')); 
echo $this->CamelCase->getSomething();
echo $this->Form->create('MyModel');
...
?>

As you can see from the example above, the usage of the helpers is different from what you are used to. Instead of $form->create() I used $this->Form->create(). It’s more to write, but I think it is more consistent with the rest of the framework.

What do you think about this approach?

Update (2008-08-28): Thanks to Rafael Bandeira’s idea it is no longer necessary to call the loadHelpers() method in your views, just copy the following method to the AppView and it will auto-load the helpers when they are needed:

public function __get($property) {
    $this->loadHelpers(array($property));
    return $this->{$property};
}

And so I looked for a different approach and ended up with a modified PagesController, combined with a route. The idea is to use the convention that each file in app/views/pages can be accessed like example.com/file (i.e. about.ctp is accessed as example.com/about and about/company.ctp as example.com/about/company).

Here is the PagesController:

// app/controllers/pages_controller.php
class PagesController extends AppController{
    public $uses = array();

    public function display() {
        $viewFilename = array_pop($this->params['pass']) . '.ctp';
        $viewFilename = str_replace('-', '_', $viewFilename);

        $viewPath =  DS . $viewFilename;
        if ($this->params['pass']) {
            $viewPath = DS . implode(DS, $this->params['pass']) . $viewPath;
        }

        if (file_exists(VIEWS.'pages'.$viewPath)) {
            $this->render(null, null, VIEWS.'pages'.$viewPath);
        } else {
            $this->cakeError('error404');
        }
    }
}

To get the aforementioned URL scheme we have to define a “catch all” route in app/config/routes.php:

Router::connect('*', array('controller' => 'pages', 'action' => 'display'));

This route has to be the latest route in the routes file. And that’s also the disadvantage of this approach: because of the “catch all” route you have to define routes for all controllers…

Anyway, I hope this approach is useful for some of you :)

One idea is to move the functionality to the AppModel. That works, but it is a dirty solution. The AppModel should contain generic functionality relevant for all models, and not functionality specific to only two models.

Another idea is to move the functionality into a class in the vendors folder and to load it with App::import(). That works fine, but if you compare this solution with elements and helpers for reusing view functionality, and with components for reusing controller functionality, it is a bit strange there is no “native” solution for models (sure, there are behaviors, but they are not designed for the kind of code reuse I described above).

Hence I think it would be useful to have model “components”, which could be realized in the same way as controller components are realized. For example:

class Example extends AppModel {
    public $components = array('X');

    public function doSomething() {
        ...
        $this->X->doSomethingElse(); // using model component
        ...
    }
}

In the longer term it would even make sense to have a unified “components” concept to replace the current concepts of components and helpers. But well, we will see what the future brings ;-)

If you look at the Model class you will see that it represents two different “things”: on the one hand it represents a single record, and on the other hand it represents a table (or to be more generic: a container of records). That’s not that clean from an object-oriented point of view, and hence I think it would make sense to split the Model class into two parts, e.g. Record and Container. All properties and methods related to a single record would be in the Record class, and all table-oriented functionality in the Container class (see also the “Managers” section in the Django book, which describes a very similar concept). In practice it could look like:

$post = $this->Posts->findById(1); // Posts is a Container which returns a Post object (a Record class)
$post->delete(); // delete the post with id 1

Maybe this is something for CakePHP 2.0?

If you look carefully at the API of the Model class, you will see that the current implementation assumes quite a bit about your models which doesn’t have to be true. So it assumes that you want to be able to find, update, save, and delete records through the model. Even though that’s often the case, it’s not always true. For example, you may want to have a read-only model. It’s something you cannot implement elegantly with CakePHP, as your model will always inherit methods like deleteAll(), save(), etc., and so those methods are part of the API of your model…

There are at least two possible ways to improve this.

The first approach is to make all such methods in Model protected. That means you could use those methods only from within your models. If you want to provide a delete-method, you would have to explicitly define such a method in your model and to delegate to the appropriate method from Model. The disadvantage of this approach is that it probably breaks a lot of code…

The second idea is to split the aforementioned functionality of the model into different behaviors. When writing your own model you can then choose which behaviors your model should have. For example, your model would use a “deletable” behavior if it should allow to delete records.

I am sure there are better ways than those I described here. They are simply thought as an inspiration to think about improving the model and to make it less fat ;-)

Anyway, what I realized by this incident is that the implementation of this entire concept is unnecessary “complex”. I must have been blind I didn’t saw this earlier ;-)

If you, for example, want to add some functionality to the AppController, you have either to copy the file app_controller.php from the “cake” (resp. new “cake/libs/controller”) folder to the “app” folder, or you have to create the file yourself in the “app” folder. That’s because you shouldn’t edit any files in the “cake” folder and its subfolders. This often leads to confusion: if you tell a newbie he should add something to “app/app_controller.php”, then the file is not there…

But it also makes the life of the (framework) developers a bit harder, as you have to check whether the files exist in the “app” folder, and depending on this check you then load the files either from the “app” or “cake” folder.

Sure, the aforementioned topics are no big deal, but on the other hand there are no benefits in doing it in the way it is currently done (or at least I don’t see any benefits).

A simpler solution would be to add AppController, AppModel, and AppHelper to the “app” folder by default (which is already done by the bake script when you bake a project). So those classes in the “cake” folder would be redundant and could be removed (and you could forget what I wrote above). KISS, keep it simple and stupid!

Let’s start with another question: what do we do on the web? We read news, we compare prices, we buy products, we learn, we look at pictures, etc., in short we are interested in content. Content is king. So the design of the sites is not that important. Of course it is more pleasant if a site has a nice design, but that’s not the reason a site is visited. It’s because of its content.

So we can say the web is about content. Ok. But HTML and CSS are primary for design purposes. Hm. Could it be that HTML and CSS are a wrong solution for websites? It is possible. There are some indicators for that:

• HTML and CSS are (too) complex, which makes it difficult for non-technical people to create websites
• too much time must be invested to make a website look correct in the different browsers
• extra work is needed if a website should be accessible for disabled people

What could be an alternative? I think an alternative approach should be similar to plain-text email, with no possibilities to format anything. So it would be really easy to create content, just open an editor and start writing (like writing an email). And you would no longer have to worry about the different browsers, because the content is shown in the way it was entered, with just one font and one font size…

What do you think about this topic?