Cake 1.2 RC1

We've been heads-down like crazy with this project. Almost all of our first-passes on our apps are complete. We are currently at 118 tables.

Something fun about the RC1 release: SQL conditions are now put in the KEY of the conditions array rather then VALUE of the array. For example:

Old:

$conditions = array('Foo.bar' => '> 23');

New:

$conditions = array('Foo.bar >' => 23);

Using YUI with CakePHP

After thoroughly evaluating prototype/scriptaculous, jquery, YUI, GWT, mooTools, and several other javascript frameworks, we've decided to use YUI for our application.

• Code size
  
• YUI Loader helps us sort out rendering speed and script dependency issues easily
  
• Yahoo serves the javascript so we can count on it not blocking download of other items
  
• Yahoo's Rich Text Editor is on-par with fck (our previous solution) and TinyMCE, for our needs, and is very very small.
• Yahoo's ConnectionManager does a lot of the caching work automatically that we'd have to reinvent the wheel with prototype.

These are some of the reasons, but not the only ones.  End result, YUI will work best for us.

So I've taken up the task of writing a YUI helper to replace a lot of the neat functions cakephp gives us. 

More to come soon!

Creating Parameterized URLs From a Form

We want to generate user-friendly search result and reporting URLs for our application.

We discovered that Router::url() will take a controller/action/params array and generate a URL, but we ran into two issues:

• It doesn't work with associative arrays (understandable), so we had to mangle our date selects
  
• We wanted to have named values (e.g. month:January) in the parameters to make it easier to generate report URLs by hand , so find('list') wasn't quite going to cut it.

Here's how we decided to do the searches:

1. Postback to search form
2. merge date selects into temporary $params array
3. findById() on each item and add the resulting names to the  $params array
4. redirect to Router::url($params)

Validation

While we begin work on data conversion into our final draft data model I've begun to work on the baked models. Adjusting source to match our style guide and adding the final validation rules. Below is a method I'm using to validate a field IF it's empty. The vine method was dropped into app_model and the array at the end is an example of use.

(This is a copy-and-paste early version, I'll post the final version of vine() as soon as I can)

/**
* V.I.N.E. - Validate If Not Empty
* Validates a field against given validation rule if it's not empty
*
* @param array $data
* @param string $fieldName
* @param array $validationRule
* @return bool
*/

public function vine($data, $fieldName, $validationRule)
{
$valid = false;
if (!isset($fieldName) or !isset($validationRule)) {
 return false;
}
if (empty($data[$fieldName])) {
 return true;
}
$validator = $this->validate[$fieldName];
$Validation = new Validation();
$method = array_shift($validator['rule'][2]);
$params = am($data[$fieldName], array_values($validator['rule'][2]));
$valid = call_user_func_array(array(&$Validation, $method), $params);
if (!$valid) {
 $this->invalidate($fieldName, $validator['message']);
}
unset($this->validate[$fieldName]);
return $valid;
}

// Example use

'tollFreePhone' => array('rule'     => array('vine', 'tollFreePhone', array('between', 7, 255)),
          'required' => false,
          'message'  => 'Toll-free phone must be between 7 and 255 characters.'),

Reminder About Data Models

Since you aren't forced to write all the SQL queries in CakePHP, you can be more descriptive with your column names.

Early Data Model & Scaffolding

We've finished with our draft data model and have started our git project. Normally we use CVS however git gives us some flexibility CVS and SVN cannot match.

Our new data model is - for now - one database with 65 tables. Quite a far cry from our existing structure.

We've placed our cake svn checkout (we'd rather use git and import the cake svn into that however the way cake uses svn makes this troublesome at best) in our standard 3rd party location and each developer will have a git checkout in their public_html directory. We have also symlinked each developers public_html into the document root (the dev server has nothing in it's default document root except these new directories) so we don't have to worry about mod_rewrites RewriteBase. This means each developer can use domain/user/checkout to view their checkout rather then domain/~user/checkout. This avoids expantion of ~ which is the reason for the RewriteBase when using mod_rewrite.

When rsync'ed into production the webroot directory will be the new document root and the core cake libs will be in their proper location (separated even from our own cake project files).

Some interesting points I've found out while doing test-scaffolding:

1. Review the default validation option bake suggests. Sometimes this will show you errors in your model (e.g. name field and bake suggests numeric for validation, foreign key field [foo_id] and bake suggests no validation, etc.).
2. Even if you aren't sure what your params will be for validation, select one that's close and give yourself the placeholder for validation later.
3. Remember the use of the fields when selecting validation - for example: vanityNumber may have letters in it so don't select "phone" as the validation scheme.
4. Follow closely the relationships suggested by bake. When you find one missing, stop and check your data model. After you fix the error, start building that model again.

Now, we still aren't writing any code. It's been a week and we are doing only test model building using bake and data model changes.

Data Modeling

We have been reworking the data model in UML. Mostly using Visual Paradigm.

The core team members got together and reviewed the existing applications - verifying each data model puzzle piece as we went - making sure all our bases were covered. So far our new data model is (currently) 1 database and 65 tables. That's a far cry from the organicly altered existing data model.

Using the UML tool we tinker then export using the ORM feature of the UML tool to the draft database. We've decided on a DRAFT-1 of the data model and have found only a few small tweeks in the draft. We have all agreed no model or controller code will be written until the data model is finished.

One thing we have found out - Once your model is in VP, good luck getting it out.

- Update: Visio won't even open the available exports from VP so... we are stuck with VP for now. I may build an InnoDB version just so I can reverse the ORM into another tool later.