zahnster

Maybe because they’re so undocumented and ambiguous, but there’s something about Cake URL routes that have both fascinated and frustrated me. In my one+ year history with Cake, I have gone about several methods of planning and executing routing, striving to provide a clean, relevant (& seo friendly) url structure without being counterproductive to the conventions of Cake.

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.

More >>

Do you develop in Cake? If so – have you ever wondered what that mysterious level 3 debug (with the ‘full object dump’) did?

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.

More >>

Ever since getting on the rapid development framework bandwagon, the one part I’ve not been totally sold on is the use of helpers, specifically, helpers which replace HTML code.

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?

More >>

Cake, the rapid development framework for PHP, makes life 10,000% easier for developers everywhere by providing us with an ActiveRecord pattern for performing the most used database interaction methods: Create, Read, Update, and Delete (CRUD). It’s modeled closely off of Ruby on Rails’s ActiveRecord, for those who are more familiar with that framework.

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.