CakePHP 1.2 sexyness is mainly a result of its convention over configuration methodology. Theoretical discussions aside, conventions save us (developers) valuable time, and allow us to concentrate on where we should put our effort: business logic. Some conventions may go under the radar until you find what you think is a weird bug. Let’s see an example by building a simple action in a controller:

Continue Reading »

While enjoying the wonderful CakePHP live show (don’t despair, I will be on soon, adding some of my latin flavor to spice up phishy’s boring comments… just kidding , PhpNut made a remark that is worth listening to: CakePHP 1.2 allows you to override CakePHP’s defined tags. Yeah, I know, so did CakePHP 1.1, but now you can define your own base helper, from which all CakePHP helpers will inherit, and only override the tags you decide. That’s right, no more copying tags.ini.php to modify it. Just define what you need, and how you need it. Let’s see how.

Continue Reading »

Even if Model::set seems to have a defined functionality, it wouldn’t be insane that you get stuck with a common developer mistake: forget what you should expect of a method. Consider the following code running on a controller (where Model is an example model, and assume validates() always returns true):

$this->data = array('Model' => array('field1' => 'value1', 'field2' => 'value2'));
if ($this->Model->set($this->data) && $this->Model->validates()) {
	unset($this->data['field1']);
	$this->Model->set($this->data);
	$this->Model->save();
}

Would you be expecting that field1 gets saved to the Model table, or not? The answer is: it will, since calling Model::set() WILL NOT empty your previously set data, but instead do a merge (so does the Controller::set method, so it’s not a CakePHP mistake, but a common coder’s misunderstanding). The solution is: if you need to set your model data making sure that you start with a “fresh” copy of the model instance, then change your set() call to create(), like so:

$this->data = array('Model' => array('field1' => 'value1', 'field2' => 'value2'));
if ($this->Model->set($this->data) && $this->Model->validates()) {
	unset($this->data['field1']);
	$this->Model->create($this->data);
	$this->Model->save();
}

One of CakePHP 1.2 coolest features are known as HABTM with models, which are particularly useful when you have a hasAndBelongsToMany binding between two models that may contain extra information (i.e: table fields) attached to the binding. They are also extremely useful when you need to make some model operations to the join table and feel too lazy to modelize it yourself, or when you have modelized the join table and need to tell CakePHP to use your own model as the join model.

Continue Reading »

I love CakePHP’s Configure class, available both in CakePHP 1.1 and 1.2 branches. It is extremely useful to store application settings that you may need application-wide. What I normally do is add this line to app/config/bootstrap.php:

Configure::load('config');

And then I create a file named app/config/config.php with all my application specific settings, like so:

$config['Settings'] = array(
	'version' => '1.0.213',
	'title' => 'My Application'
);

You can naturally later access any of these settings by doing something like:

$title = Configure::read('Settings.title');

Now, I also like to categorize my settings in different sections, so my app/config/config.php may look a little more like this:

$config['Settings'] = array(
	'version' => '1.0.213',
	'title' => 'My Application'
);

$config['Cache'] = array(
	'queries' => true,
	'views' => false
);

But here comes the important tip: allways consider that someone else has already defined a setting with the same category you are specifying. Why do I say this? Because CakePHP 1.2 is moving all its settings to a Configure approach, and its already utilizing some configuration categories that you may be using, like App. In fact, if you just define a new App category, it will overwrite CakePHP’s built in App category and result in your application going to hell. Well, not hell particularly, but it will surely not work as expected. So instead, define each category like this:

$config['Settings'] = Configure::read('Settings');

$config['Settings'] = Set::merge(ife(empty($config['Settings']), array(), $config['Settings']), array(
	'version' => '1.0.213',
	'title' => 'My Application'
));

This way we are making sure that if there are settings already defined in that category, we add our own to it instead of overwriting it entirely.

I’ve just finished reading dho’s goodbye message to the CakePHP team. While I may or may not agree with Daniel’s feelings of being left behind, the thing that should always matter are actual facts, not feelings.

The fact is that I was present the day CakePHP’s developers channel changed its password. At that time, it was very clear to all of us (CakePHP team) that whoever was not contributing to CakePHP as an ongoing and active project was no longer going to have access to the channel.

Continue Reading »

When analyzing developers performance and how outside factors influence their productivity, there’s little to no reference regarding the work environment, not particularly a developer’s relation to their coleagues, but mostly to the physical location on which their work is being undertaken.

In Argentina and most countries with at least some offshore culture, most big software factories believe that productivity increase is the sole result of salary increases, neglecting how important an office location / disposition is to make a substantial difference. It is very common to find hundreds of developers working side by side on a flat table, with little to no independence among each other.

Continue Reading »

Tom OReilly produced a handy solution on the bakery (Keeping bindModel and unbindModel out of your Controllers) to allow to overcome performance issues when querying a model that has a lot of associations with other models. While his solutions prooves useful, I wanted to change it mainly because I didn’t want to have to re-define the way associations are defined on Cake.

So I’ve built a function hooked to AppModel to allow to define what associated models you want to get when querying a model. If you don’t use the function, you get CakePHP’s usual result. If you call it with no parameters, you only get the model you are querying (no associated models.) Finally, you define your relations the normal way.

I’ve produced a tutorial on the bakery that illustrates this: An improvement to unbindModel on model side. It is still pending publication so if you get Article Invalid be patient and try tomorrow The following is an example of how you would use it to query the Post model and only get the related author, eventhough the Post model may have associations to other models (such as Category, Comment, etc.)

$this->Post->expects(array('Author'));

$result = $this->Post->findAll();