Here an example from the API:

# app/views/posts/index.atom.builder
atom_feed do |feed|
  feed.title("My great blog!")
  feed.updated(@posts.first.created_at)

  @posts.each do |post|
    feed.entry(post) do |entry|
      entry.title(post.title)
      entry.content(post.body, :type => 'html')

      entry.author do |author|
        author.name("DHH")
      end
    end
  end
end

The code should be self-explanatory (if not, please leave a comment).

Recently, I had two such views which were almost identical, the only difference was the feed title. And that’s of course not really DRY.

One possible approach to fix this “issue” is to set an instance variable with the feed title in the controller and render the same view in both cases. As I don’t like to set view titles (resp. feed titles in this case) in the controller, I decided to use a partial.

And so I put the code from above into a partial (plus changing the instance variable “@posts” to a local variable “posts” and introducing a new local variable “feed_title”), and tried to use this partial (app/views/shared/_feed.atom.builder) in the following way:

# app/views/posts/index.atom.builder
render :partial => 'shared/feed', :locals => {:feed_title => "My Posts", :posts => @posts}

Well, it didn’t work. No output was generated.

After experimenting a bit I found the following solution by moving the outer-most block definition from the partial to the views:

# app/views/posts/index.atom.builder
atom_feed do |feed|
  render :partial => 'shared/feed', :locals => {:feed => feed, :feed_title => "My Posts", :posts => @posts}
end

I don’t know whether this is the best solution (probably not), but it is definitely better than what I had previously ;-)

That’s nice, however, in our case all JSON views are identical (the same applies for the XML views):

// requires the JSON part from the Zend framework
App::import('Vendor', 'json', array('file' => 'Zend'.DS.'Json.php'));
echo Zend_Json::encode(array('data' => $data));

And so following the default approach would lead to a lot of duplication and many unnecessary folders and view files. And that’s not that cool ;-)

After some experimentation I found a better way.

For each extension I created a folder with a default view:

app
  views
    json
      default.ctp
    xml
      default.ctp

json/default.ctp contains the code I have shown above, and xml/default.ctp would look like:

echo $xml->serialize(array('data' => $data), array('format' => 'tags'));

To tell CakePHP it should render those default views when there is not a more specific view, I added the following beforeRender() callback method to the AppController:

// app/app_controller.php
class AppController extends Controller {
    public function beforeRender() {
        $pathToViewFile = dirname(__FILE__).DS.'views'.DS.$this->viewPath.DS.$this->action.'.ctp';
		
        if (!file_exists($pathToViewFile)) {
            $this->viewPath = $this->layoutPath;
            $this->action = 'default';
        }
    }
}

Happy baking!

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};
}

The first two approaches use the magic variable “title_for_layout” to set the title in the layout:

<title>
    <?php echo $title_for_layout;?>
</title>

You can set the value for this magic variable either in the controller:

public $pageTitle = 'The title';  // same title for all actions

or

public function test() {
    $this->pageTitle = 'The title';
    ...
}

or in the view file:

<?php $this->pageTitle = 'The title';?>
...

The third, and last, approach uses a custom variable in the layout instead of the magic variable:

<title>
    <?php echo $pageTitle;?>
</title>

Its value is then set in the controller, in the same way you put other data to the view:

public function test() {
    ...
    $this->set('pageTitle', 'The title');
}

Now, which approach should you use? I think it is a matter of preference. From a conceptual point of view I prefer the third approach as it doesn’t use any magic, but in practice I usually use the second (maybe this will change after this article *g*). The first approach I consider as a bad practice, because a controller doesn’t represent a page and hence it shouldn’t have a pageTitle property.

boolean is self-explanatory: it validates whether a field contains a boolean value (i.e. 0, 1, “0″, “1″, false, or true). Example:

var $validate = array('is_enabled' => array('rule' => array('boolean')));

inList ensures that the respective field only contains a value from the defined array. It is case-sensitive, i.e. if you use the rule from the example below, then the value “Red” would be invalid.

var $validate = array('color' => array('rule' => array('inList', array('red', 'green', 'blue'))));

time determines whether a field contains a valid time value. It supports both the 24 hour format (e.g. 08:10:10) and the 12 hour format (e.g. 8:10:10am). The minutes and seconds are optional in both cases.

var $validate = array('starttime' => array('rule' => array('time')));

Another recent change affected View::renderElement(): it has been deprecated in favor of View::element():

$this->renderElement('my_element', array('param1' => 'a value'));

becomes

$this->element('my_element', array('param1' => 'a value'));

I don’t know why View::renderElement() was deprecated and not View::element(), as I think the method name “renderElement” is more expressive than “element”.

Anyway, happy baking :)

To prevent this effect, we have to detect the type of view which is rendered. The only way I found to accomplish this, is to check the viewPath, as shown in the following snippet:

// in app/app_controller.php
public function beforeRender() {
    if ($this->viewPath != 'errors') {
        // no error page
    }
}

It is probably rather rare you have to use this, but maybe it is useful for some.

At first we have to get the Jeditable plugin (plus the JQuery library if you don’t have it already) and place it in app/webroot/js. In this folder we also create a js file which will contain the Javascript code we have to write (I will name this file example.js).

To use the Javascript files, we have to include them in the layout (or in the view, see “Referencing Javascript files” for more information):

// app/views/layouts/default.ctp
<?php echo $javascript->link(array('jquery-1.2.3', 'jquery.jeditable', 'example')); ?>

Don’t forget to add the Javascript helper to the $helpers array of your (App)Controller.

The next step is to write the “normal” functionality of the application, in this example we simply list the titles of all posts. The controller (app/controllers/posts_controller.php):

class PostsController extends AppController {

    public function index() {
        $this->set('posts', $this->Post->find('all'));
    }
}

And the view (app/views/posts/index.ctp):

<?php foreach ($posts as $post): ?>
    <div class="post" id="<?php echo $post['Post']['id']; ?>"><?php echo $post['Post']['title']; ?></div>
<?php endforeach; ?>

With that we are ready to add the edit in place functionality. Thanks to the Jeditable plugin this is an easy task: we only have to define the editable element(s), the url to which the changes should be posted, plus some parameters.

// app/webroot/js/example.js
$(function() {
    $('.post').editable('/posts/updateTitle', {
         id        : 'data[Post][id]',
         name      : 'data[Post][title]',
         type      : 'text',
         cancel    : 'Cancel',
         submit    : 'Save',
         tooltip   : 'Click to edit the title'
    });
});

I think this code is self-explanatory (if not, please leave a comment), so we can go on to implement the updateTitle action. We also add the RequestHandler component to our controller, so that the response of the updateTitle action automatically uses the ajax layout:

class PostsController extends AppController {
    public $components = array('RequestHandler');

    public function index() {
        $this->set('posts', $this->Post->find('all'));
    }

    public function updateTitle() {
        if ($this->data) {
            App::import('Core', 'sanitize');
            $title = Sanitize::clean($this->data['Post']['title']);

            $this->Post->id = $this->data['Post']['id'];
            $this->Post->saveField('title', $title);
            $this->set('posttitle', $title);
        }
    }
}

Last, but not least, we have to create a simple view for the updateTitle action (app/views/posts/update_title.ctp):

<?php echo $posttitle;?>

That’s it, our application now provides edit in place functionality. Happy baking :)

cake bake model User
cake bake controller Users scaffold
cake bake view Users

For more details on those shortcuts call the bake script with the help parameter like:

cake bake model help

or have a look at Faster baking of controllers with the bake shell script and Baking views.

Recently, a new shortcut was added which makes the aforementioned shortcuts (almost) obsolete. With the “all” parameter it is now possible to bake with one command a model plus the corresponding controller with its views:

cake bake all  // asks you for the model name
cake bake all User

This feature is currently only available in the development branch, but the next release is probably not that far away…

Happy baking :)

In the meantime this feature has been added to the development branch (I don’t know when) as I learned today from a comment by gwoo.

If you have an element /app/views/elements/example.ctp in your application, then you can render it with the following code snippet from within your controller:

$this->render('/elements/example');

In the same way you can also render views which belong to other controllers.

Now someone called “voidstate” posted a little trick in the CakePHP Google Group which makes it possible to get code completion in the view for helpers. For this purpose you have to create a PHP file somewhere in your project (it doesn’t matter where) with the following content:

<?php
 // stop page loading
 exit; 

// reference helpers so Eclipse provides code completion
 $ajax = new AjaxHelper();
 $cache = new CacheHelper();
 $form = new FormHelper();
 $html = new HtmlHelper();
 $javascript = new JavascriptHelper();
 $number = new NumberHelper();
 $session = new SessionHelper();
 $text = new TextHelper();
 $time = new TimeHelper();
 ?>

As soon as the file is stored, you should have code completion. Thanks to voidstate for this trick!