CakePHP allows you to use your own "find-types" for the Model::find() methodology. Those of your who are familiar with the find() method know that there are currently four types in the core: 'list', 'all', 'first' and 'count'. However, sometimes it is nice to specify your own type.

He shows an example of the end result - a find() call with a custom type that automagically gets translated correctly. His script overrides and enhances the usual find call in an extended object (extended from AppModel) that uses a switch/case statement to define the custom types and their find() search calls.

When asked the time, we generally don't need to be military accurate with our response [...] we generally communicate the approximate time. i.e. 'its nearly ten' or 'its just gone half past three'. Yet on the web, time is generally shown as '12:24:13 AM', or similar â€" not very visitor friendly.

His RoughTime uses two switch statements to map the hour and minute values to different strings. For example, minutes between 15 and 20 become "quarter past" and the hours are changed over from numeric versions to their word counterparts.

I got curious about which is actually more efficient at matching a random integer with a set of conditionals. So, I setup a script to create a set of large scripts to test the speed of these different constructs. Using the 'time' command, I measured the speed at which the condition could match a random number.

His results found that the switch statement is generally more than 2 times as fast at matching a simple integer. His tests, however, didn't go through much more than this simple test. It'd be interesting to see what it would do with something more complex (like longer strings or handling the result of an evaluation inside the definition of the switch().

In our last exciting adventure (back in early November), we braved crocodiles, ravenous editors, most of the PHP statements, and beginning loops. In this edition we'll cover the final statement, the Switch, and discuss arrays. So sit back, order your R2D2 robot to bring you a cold, frosty Jolt Cola, and let's get cracking.

They start with a simple example of a switch statement (to echo out strings) and follow it with a detailed description of the different sorts of arrays - numeric indexed, associative and multidimensional versions.

I have had to go through a php application recently which has given me more than one headache and has required me to use all my possible patience. While working with it, I thought This is good material for an article, so that nobody else does the same in the future, and nobody else will need to experience the same displeasure as I have had to.

So here are the signs your PHP application needs a serious refactoring, right now

Included in the list are things like:

• Uses global variables
• Everything's an array
• The neverending switch
• Interface inconsistency

It hits on one of the thing that bugs me too, the problem of "Brackets galore" - so many subarrays that you have to resort to three or more sets of bracketed keys to get to the value you want. It's bad enough trying to follow someone else's code without having to "trace down" an array to figure out which of the values they're talking about.

Several weeks back, a bug was reported against Zend_View that had me initially stumped. [...] Basically, __get() no longer returns a reference and returns values in read mode, which makes modifying arrays using overloading impossible using traditional methods.

He gives a code example of the problem and two ways to get around it - one using a switch statement to get around the problem and the other ("best solution") was Matthew's option to extend the ArrayObject class.

Of all the graphs in The State of Web Development 2006/2007 report that SitePoint and Ektron published recently, the one that stood out the most to me was the one showing the platform currently being used by developers planning to start using Ruby on Rails.

It wasn't the fact that the graph shows PHP developers to be likely to start using Rails-this makes sense, as someone is more likely to experiment with another open source platform if they're already using another open source platform-it was the fact that PHP developers are more than three times as likely to start using Rails, even more so than Java developers!

Unfortunately, the study mentioned isn't too cheap, otherwise it would be interesting to see the info behind this graph....

To make it simpler for developers to access this templating system, Matthew created the Cgiapp2_Plugin_Template_Interface, a standardized interface for the template plugins. It's this interface that he demonstrated an example of, giving only a few lines of code (all that's needed) to switch between Smarty and Savant templating systems.

The post outlines a process to allow both the Zend Core and a normal installation of PHP 5.1.x to live peacefully (and still be able to switch from one to the other at any time). It's actually a relatively simple ten-step process to follow, especially if you've had much experience with installing PHP from scratch. When complete, you can start up one or the other, making it easy to test scripts in both or to just use the functionality in one (as he needed with PDO).

In my recent post on 'Ajax; Templating; and the Separation of Layout and Logic,' I refer to an Ajax Handler that sits server side to handle Ajax calls. Some elaboration is in order.

As I have stated in the past, I'm a huge fan of Prototype AND I choose PHP as my language of choice...so my examples will be using both, but the idea is portable.

His example is a very basic one, pulling in the data from the $_GET values and, with a combination of dynamic function calls and the use of eval(), provides a simple "framework" to handle your Ajax calls. There are two versions of the same thing - one using if statements and the other a switch and various cases.]]> Thu, 23 Mar 2006 12:37:17 -0600