I’m not gonna go through custom find types, you can find more info about them at Matt’s blog, or at this article written by someone whose name I think I’ve heard somewhere. What I’m going to talk about is how to mix your custom find types with pagination, without having to use paginate and paginateCount in your models.

So let’s first start by building yet another posts table, and inserting some records:

CREATE TABLE `posts`(
	`id` INT NOT NULL AUTO_INCREMENT,
	`title` VARCHAR(255) NOT NULL,
	`body` TEXT NOT NULL,
	`published` TINYINT(1) NOT NULL default 0,
	`created` DATETIME,
	`modified` DATETIME,
	PRIMARY KEY(`id`)
);

INSERT INTO `posts`(`title`, `body`, `published`, `created`, `modified`) VALUES
	('Post 1', 'Body for Post 1', 1, NOW(), NOW()),
	('Post 2', 'Body for Post 2', 0, NOW(), NOW()),
	('Post 3', 'Body for Post 3', 0, NOW(), NOW()),
	('Post 4', 'Body for Post 4', 1, NOW(), NOW()),
	('Post 5', 'Body for Post 5', 1, NOW(), NOW()),
	('Post 6', 'Body for Post 6', 0, NOW(), NOW()),
	('Post 7', 'Body for Post 7', 1, NOW(), NOW()),
	('Post 8', 'Body for Post 8', 1, NOW(), NOW()),
	('Post 9', 'Body for Post 9', 1, NOW(), NOW());

Now let’s assume we want a find type called published to fetch only the published posts, and that we also want to be able to paginate using this find type. We will be approaching this through a generic approach, something that can be used throughout all our models. With this in mind, let’s first introduce a model based member variable called $_types, where we define the specific needs of each custom find type. Therefore, that variable will hold what we need as conditions, order, etc. for each custom find type. So let’s build our Post model:

<?php
class Post extends AppModel {
	public $name = 'Post';
	protected $_types = array(
		'published' => array(
			'conditions' => array('Post.published' => 1),
			'order' => array('Post.created' => 'desc')
		)
	);
}
?>

As you can see, we define options for each find type as if we would be calling find() directly. So with the above, instead of doing:

$posts = $this->Post->find('all', array(
	'conditions' => array('Post.published' => 1),
	'order' => array('Post.created' => 'desc')
));

We can now do:

$posts = $this->Post->find('published');

Now, what if we wanted to paginate with the above custom find type? Just as we set pagination parameters through the controller member variable $paginate, we can specify which find type pagination we’ll use. We do so by specifying the find type in the index 0 of the pagination settings. Like so:

$this->paginate['Post'] = array(
	'published',
	'limit' => 10
);

$posts = $this->paginate('Post');

Easy, huh? When this is specified, paginate() does the following:

1. It issues a find('count') on the Post model, specifying the custom find type (published) in the $options array, through an option named type. Therefore, we can use $options['type'] when our model is about to do the count to use the given options for our custom find type.
2. It fetches the records by calling find() with the custom find type, find('published') in our example.

So where’s that sexy code? Add the following in your AppModel, making the above available for all our models.

<?php
class AppModel extends Model {
	public function find($type, $options = array()) {
		if (!empty($this->_types)) {
			$types = array_keys($this->_types);
			$type = (is_string($type) ? $type : null);
			if (!empty($type)) {
				if (($type == 'count' && !empty($options['type']) && in_array($options['type'], $types)) || in_array($type, $types)) {
					$options = Set::merge(
						$this->_types[($type == 'count' ? $options['type'] : $type)],
						array_diff_key($options, array('type'=>true))
					);
				}
				if (in_array($type, $types)) {
					$type = (!empty($this->_types[$type]['type']) ? $this->_types[$type]['type'] : 'all');
				}
			}
		}
		return parent::find($type, $options);
	}
}
?>

Now ain’t CakePHP great? Don’t tell me, tell everyone at CakeFest #3.

Related posts:

1. Modelizing HABTM join tables in CakePHP 1.2: with and auto-with models
2. CakePHP tip of the day: pay attention to conventions
3. CakePHP 1.2 tip of the day: be mindful of Model::set

What better place to talk CakePHP than the world’s beer nation? That was the question that made the CakePHP Team decide CakeFest third edition should be located in Berlin, Germany. Just as Buenos Aires was the meat fest, I hereby predict that this will be the Beer Fest.

Let’s face it, your code gets better when you use CakePHP. So attending the official CakePHP gathering where all Core Developers and prominent community members go to share their knowledge is an offer you should not ignore. Add awesome beer and guaranteed fun to that recipe, and you would be insane not to join us.

So what are you waiting for? Go and get your CakeFest ticket as soon as possible, you don’t want to be left behind! If you have a company, or you are a regular Baker just wanting to show your love back to the project, do not hesitate to sign up for the sponsorship packages. Also help us spread the word by placing these CakeFest badges in your site, and you may even get a free ticket!

Related posts:

1. CakePHP 1.2 beta released and CakeFest site launched
2. My talk in CakeFest: behaviors
3. CakeFest was a success

for file in `find . -name "*.thtml"` ; do svn mv $file `echo $file | sed s/\.thtml/\.ctp/` ; done

After that you can safely commit. Enjoy!

Related posts:

1. Simple backup script for Ubuntu
2. Using Configure in CakePHP applications

I came back to Buenos Aires the day before yesterday, after a wonderful experience in Orlando. CakeFest was not only a great opportunity to be a part of the first official CakePHP gathering, but most importantly to meet a lot of smart people. As I said to someone while in Orlando, eventhough all the talks were thorough and hands-down interesting, I found that the after hours were the moments where I got most out of the conference. Just hanging out with fellow bakers, drinking beer (lots of beer) and talking code to each other was an incredible opportunity.

I enjoyed my time there so much that I came back completely decided to host a CakeFest in Buenos Aires, Argentina during the first week of December, 2008. I am already taking care of the organization and will open up inscriptions very soon (so now you can’t complain, you have almost 10 months of notice.) Some of the talks will be english and some in spanish, so everyone is invited to join. As a corolary, I’ll leave you with some pictures taken in Orlando (wish I would’ve taken more). Click on the pictures to get their respective bigger size photos.

DOWNLOAD: In case you are interested, you can download the slides of my presentation entitled Behaviors: Making your Models Behave.

Lunch	Chit chat at salad bar
Gwoo and his Mac	Gwoo’s keynote
Felix (the_undefined), Tim and me	Jeff (phishy) and me. Marc in the background.
Dennis and me	Some of CakeFest team

Related posts:

1. CakeFest #3: CakePHP in Berlin, July 9-12
2. CakePHP 1.2 beta released and CakeFest site launched
3. CakeFest #2 coming up

With just hours left to launch the first CakeFest conference, people are starting to show up and speakers are working ’round the clock with their presentations. However, something has been catching my attention since I came to the hotel: I am different. That’s right, I am unique. I stand out as an oasis in the middle of the desert. Don’t take my word for it, just look at my dear old Thinkpad standing in a pool of Macs. And in case you are wondering, people there from left to right are: Jeff Loiselle (aka phishy), Felix Geisendörfer (aka the_undefined), Tim Koschuetzki, and giving his back is Dennis Hennen.

Related posts:

1. CakeFest was a success
2. Seven Things You Don’t Know About Me (MEME)

With the recent release of the confirmed schedule for the CakeFest conference, you can see that my talk entitled Making your Models Behave has been allocated for Friday, February 8 at 11.15 am. Right after Nate’s keynote, and before lunch, what an honor

For those of you who are attending my talk will be focused in understanding and exploiting the potential of what I consider to be one of the coolest features CakePHP has brought us: model behaviors. And for those of you who are not going, what are you waiting for? There are still tickets available. Reserve your flight and your stay, and head on to the conference.

If for some reason or another you are not going, we will be releasing the presentation slides on the CakeFest site sometime in the feature.

Related posts:

1. CakeFest #3: CakePHP in Berlin, July 9-12
2. CakeFest was a success
3. CakePHP 1.2 beta released and CakeFest site launched

A lot has happened in the last few weeks, but it all came together today: CakePHP 1.2 has reached its beta status and the CakeFest website has launched officialy. CakeFest is the first official gathering related to CakePHP, and will be celebrated in Orlando, Florida, on February 6, 7, and 8, 2008. You’ll get a chance to see experienced CakePHP developers (that’s right, the core team will be there) sharing their knowledge in talks and different events. I will be there as well, regardless if that’s good or bad news to you all. So don’t wait any longer, go and find out about the CakePHP festivities and save your ticket

Related posts:

1. CakeFest #3: CakePHP in Berlin, July 9-12
2. CakeFest was a success
3. Response to dho leaving the CakePHP team

It’s been some time since I’ve done any work on expects, and while enjoying the incredible set of cool features CakePHP 1.2 pre-beta is giving us all, I decided it was time to let expects meet 1.2. My new baby is called ExpectsBehavior. As its 1.1 predecessor, its main goal is to provide a wrapper for CakePHP’s unbindModel function, to let the developer specify what bindings (model relationships) he’s expecting right before a find. At the same time, I needed some new features to be added, some of them courtesy of the previous brain work Felix did on his very cool Containable behavior.

So what are some of these cool new features I’m talking about?

• Parameter notation flexibility: you can choose different ways on how to specify the models you need. Whatever is sexier for you!
• Calling methods: you can use the old way (calling Article->expects() right before your find), or use the newly CakePHP find notation with embedded parameters for the behavior, specifying your expects setting right on the Model::find() call.
• Override binding settings: tired of having to do a bindModel() to override some binding settings (such as limit, order, offset) right before your expects call? Want to only get certain fields of a related model, instead of all of them? Don’t stress! ExpectsBehavior allows you to override these settings easily.
• Auto recursivity: by default, ExpectsBehavior will determine the necessary recursivity needed to fetch the models you specified, and will set the main model recursivity accordingly. This feature can be disabled via a behavior setting.
• Warnings: if you enable a behavior setting, ExpectsBehavior will issue notices when specified bindings do not really exist. By default this setting is disabled.
• Thorough testing: I’m working very hard in adding tests for almost every conceivable aspect of the ExpectsBehavior. I’m already at 433 asserts, and counting! All succeeding, naturally

Let’s start with the basics: parameter notation. ExpectsBehavior allows you to use two types of alternative notations when defining the bindings you are expecting: dot notation, and depth notation. Dot notation comes from expects 1.1, while depth notation is an alternative way where you specify the models using associative arrays. Let’s start with some samples (both calls will produce the same result):

// Dot notation

$this->Article->expects('Category', 'Comment.User', 'Tag');

// Depth notation

$this->Article->expects(array('Category', 'Comment' => 'User', 'Tag'));

Ok, let’s get a little deeper:

// Dot notation

$this->Article->expects('Category.Section', 'Comment.User.Profile', 'Tag');

// Depth notation

$this->Article->expects(array('Category' => 'Section', 'Comment' => array('User' => 'Profile'), 'Tag'));

What about mixing them up?

$this->Article->expects(array('Category' => 'Section', 'Comment' => 'User.Profile', 'Tag'));

Cool, huh? Now, with calling methods you can still call expects the way we’ve just seen (the old way), or use the new, cool way: embedded parameters. Instead of doing:

$this->Article->expects(array('Category', 'Comment' => 'User', 'Tag'));
$result = $this->Article->findAll();

Why not just do:

$result = $this->Article->find('all', array('expects' => array(
	'Category', 'Comment' => 'User', 'Tag'
)));

Wait, does that really work? Yeah it does! Really? Of course! But don’t go anywhere, there’s more. Amongst the features I mentioned you can now override binding settings. Let’s see some code! Assume we just want the fields ‘username’, and ‘email’ for the User binding on our previous call, so we simply change it to:

$result = $this->Article->find('all', array('expects' => array(
	'Category',
	'Comment' => array('User' => array('username', 'email')),
	'Tag'
)));

Or if you don’t like seeing so many arrays, use the embedded field notation:

$result = $this->Article->find('all', array('expects' => array(
	'Category',
	'Comment' => 'User(username, email)',
	'Tag'
)));

What about mixing fields and inner models? Let’s bring up the Profile attached to a User, and the Friend the user’s got:

$result = $this->Article->find('all', array('expects' => array(
	'Category',
	'Comment' => array('User' => array('username', 'email', 'Profile', 'Friend')),
	'Tag'
)));

What about other settings? Like limit, and order? Sure, no problem. Say we want to get only the first 5 tags related to the articles, and order them by their field tag. Then let’s change the above to:

$result = $this->Article->find('all', array('expects' => array(
	'Category',
	'Comment' => array('User' => array('username', 'email', 'Profile', 'Friend')),
	'Tag' => array('limit' => 5, 'order' => 'tag ASC')
)));

I’m not yet releasing it since I want to add further testing, but I will be posting the sourcecode on a live server very soon. So stay tuned, and until then I welcome your feedback.

Related posts:

1. Limiting the associated models returned with CakePHP
2. Modelizing HABTM join tables in CakePHP 1.2: with and auto-with models
3. Using Configure in CakePHP applications

class PostsController extends AppController {
	function edit($slug) {
		$post = $this->Post->findBySlug($slug);

		if (!empty($this->data)) {
			// We have the post already, so don't let user submit and ID
			// in POSTed information, just in case he gets funky ideas

			if (isset($this->data['Post']['id'])) {
				unset($this->data['Post']['id']);
			}

			$this->Post->set($this->data);
			if ($this->Post->validates()) {
				// Force correct ID
				$this->data['Post']['id'] = $post['Post']['id'];

				// Do something else we need to do before saving
				// ...

				// and now save
				$this->Post->save($this->data);
			}
		}
	}
}

To our surprise, you’ll see that the above code always generates a new Post, instead of editing the post which slug is $slug. Why is that? I’ll give you a hint: print out $this->Post->id just before you execute the validates(), and you’ll see that it is set to whatever the slug is. What? So ID is set to a slug? Now, why the heck is that? Let’s dive into CakePHP core code, and pay special attention to the first few lines of Controller::constructClasses():

if (empty($this->passedArgs) || !isset($this->passedArgs['0'])) {
	$id = false;
} else {
	$id = $this->passedArgs['0'];
}

if ($this->uses === false) {
	$this->loadModel($this->modelClass, $id);
} elseif ($this->uses) {
	$uses = is_array($this->uses) ? $this->uses : array($this->uses);
	$this->modelClass = $uses[0];
	foreach ($uses as $modelClass) {
		$this->loadModel($modelClass);
	}
}

As you can see CakePHP, when only the auto-model linked to our controller is used (i.e: we’re not using Controller::$uses), will assume that the first parameter sent to the current action (if there’s indeed one) corresponds to the model ID. Therefore on our case it is set to whatever the $slug passed was. Now you may be asking, why should that still be a problem if we’re forcing the ID right before the save? Once again, let’s dive into the core, and see that when Model::invalidFields() (called by Model::validates()) is figuring out what rules to execute during validation, it does the following so it knows if the current record being validated is a new record, or an existing one:

$exists = $this->exists();

For performance reasons, Model::exists() will save internally a variable so the next time someone calls Model::exists() it doesn’t have to execute another COUNT, unless you force it (by passing true as a parameter to exists). Model::save() naturally needs to know if the record exists to figure out if it’s an INSERT or an UPDATE. How does it find out? You’ve guessed it: by calling exists:

$exists = $this->exists();

It is not forcing exists() to re-run the query, which means on our case Model::exists() will return the value found the last time it was executed, which was back when the model was being validated. At that time Model::$id was set to $slug, so naturally Model::exists() said this record doesn’t exist. Hence, Model::save() thinks now the record doesn’t exist, and the save gets executed as an INSERT.

Now don’t get all hasty and think this is a bug, or complain saying that Model::save() should force Model::exists() to refresh. Instead think that we may be missing the point: there’s another convention which says Model should know the real Model ID before a validation is performed. It is a convention for our own benefit: so we can specify certain validation rules to run only on update, create, or both. So we need to change our code and make sure that the right model ID is set before executing Model::validates():

class PostsController extends AppController {
	function edit($slug) {
		$post = $this->Post->findBySlug($slug);

		if (!empty($this->data)) {
			// Let's force the ID, just in case user gets funky ideas
			$this->data['Post']['id'] = $post['Post']['id'];

			$this->Post->set($this->data);
			if ($this->Post->validates()) {
				// Do something else we need to do before saving
				// ...

				// and now save
				$this->Post->save($this->data);
			}
		}
	}
}

Related posts:

1. CakePHP 1.2 tip of the day: be mindful of Model::set
2. Something to consider when saving HABTM records in CakePHP
3. Pagination with custom find types in CakePHP

From IBM’s new series entitled PHP Frameworks comes our phrase of the day: “If you’ve overheard a conversation about PHP frameworks, that conversation was probably about CakePHP.”

No related posts.