Recently I had a rather unique challenge come across my plate. It was a potentially complex routing situation where the parameter needed to be between the controller and the view in the url structure. Visually, ‘/controller/parameter/view’. It made total sense seo wise, and if I could make it work right, wouldn’t affect Cake conventions at all. However, I wasn’t even sure if this method was possible.

The solution, as it turns out, was amazingly simple.

In the Routes declaration, simply set the wildcard (*) in the middle of the model name and the view name. Visually,
$Route->connect('/controller/*/view', array('controller' => 'controller', 'action' => 'view'));

There! And now you can recursively route.

This was something I have been confused over since the time I started developing with the framework – which is just over a year ago. I would set the level to 3, but never noticed a difference between the output there and the output provided by level 2 debug. I knew I was missing something, but nowhere in the Cake Manual does it elaborate on this setting or what you have to do to make it work.

Then, by chance a few weeks ago I was in the CakePHP chat room on IRC and someone told me about $cakeDebug. Apparently it’s included in the default Cake layout template, but due to my constant template creation (always right off the get go in my development process) I had never known that this needed to manually be included in your layout for the Full Object Dump to appear.

The full code reads:
<?= $cakeDebug ?>

Feel free to place that in the bottom of your custom template – when your Debug settings are set to 2 or lower, you won’t even know it’s there. However, this is the mysterious object that shows you a full object dump on level 3 debug.

Just figure I’d share.

The reasoning is that I’ve never really seen the point of them. To give an example, CakePHP has an HTML helper for creating links – and the code looks a little something like this:
<?php echo $html->link('link text description', '/path/to/link') ?>

Which isn’t really much more efficient than it’s HTML counterpart, written like this:
<a href="url">link text description</a>

In fact, the HTML is shorter to write out. So why even bother with HTML helpers?

I got into the habit of using them, mostly because when I got into the CakePHP framework, it just seemed like the thing to do. It made me feel all Cake-y, and yes, it does come in handy when you are using php variables in the link creation. However, it became abundantly clear to me the other day that it can really cripple regular website maintenance for developers who come into the project not knowing Cake.

One of my clients, who I had created a site for using Cake, needed to change a link in one of the page views, saw the $html->link() function, didn’t understand it, and thought that all links had to be created in this special way. Which is totally understandable – the client doesn’t know a lot about the Cake framework (or frameworks in general), and wasn’t aware that all the link function does is parse out an HTML link (and that he could have just used a normal HTML link and it would have been the same).

So, the question remains – are HTML helpers worth it?

As a Rails developer I’ve seen the limits of ActiveRecord, and the performance issues it gets when dealing with large, complex database types. But to be honest, I’ve never been a big fan of the Ruby language, and part of me assumed that was just Ruby being slow. I was convinced that with a good framework, ActiveRecord could be used (efficiently) in complex database environments.

Yesterday that blind faith was taken to the test as I attempted to optimize a CSV generator. The problem was simple: the query which collected a table’s information, was producing an array which was way too large – the database table had close to 60,000 records and at 9.something MB, was throwing PHP memory allocation errors left and right.

Right now it stands at Heavyweight SQL: 1 / CakePHP: 0. However, I am determined to find a way to make complex databases work well with Cake – I still have a lot to learn about this framework, and I have belief in it.