CakePHP Weekly Summaries Issue #2

March 3, 2008 – 10:37 pm

Table of Content [Hide]

Welcome

Welcome to the second edition of the CakePHP weekly summaries.
Its quite embarrassing that it had to take so long time to get the second editon out. Too long time has passed and the amount of things that has happend during that period is waaay too big to be covered here.
Therefor I present this half-done 2nd edition of the weekly summaries, with a promise that every week from now on I will give you the latest and greatest from the CakePHP world.
So with no further ado, please enjoy this old and probably rather outdated edition of the ~~weekly~~monthly summaries. See you at the 3rd edition soon

Trac changes

Changeset #6321 (phpnut) Fixes Ticket #3817, Some non-executable files in source tree have executable permissions
Changeset #6322 (phpnut) Updating controller tests created with the console. Added associated fixtures to model tests
Changeset #6323 (gwoo) Updating Cache to apply prefix for every key, closes Ticket #3821
Changeset #6324 (phpnut) Correcting links generated to additional app tests
Changeset #6325 (phpnut) Adding support for test fixture generation when creating models, this will eventually be moved to a task. Currently the $records are hard coded to create field type specific data, this will eventually be changed to create random data based on the field type. Refactored tests that are created for models, 3 working tests are not created when generating tests for the model. Added notice output to terminal when creating a project, the CAKE_CORE_INCLUDE_PATH is automatically altered and may need to be changed when moving to a production environment. ”
Changeset #6326 (phpnut) Fixes svn file property line
Changeset #6327 (phpnut) Removing unneeded ‘ : ‘
Changeset #6328 (phpnut) Removing unneeded ‘ : ‘
Changeset #6329 (nate) Fixing reading and writing in Configure class for references 3 levels deep, fixes Ticket #3845
Changeset #6330 (nate) Removing un-needed method from TimeHelper? test
Changeset #6331 (phpnut) Removing var $useTable; from generated model when tables follow conventions Fixed issue with model tests and fixtures not being created properly when Model name does not match table name
Changeset #6332 (phpnut) Updating controller tests created with the console. Added associated fixtures to model tests
Changeset #6333 (phpnut) Fixes Ticket #3849, Deprecated loadView() call in email component when using theme
Changeset #6334 (gwoo) updating HttpSocket? with auth, closes Ticket #3838 removing type casting, fixes Ticket #3827 adding socket.group to tests
Changeset #6335 (gwoo) updating component, removing use of Router not needed anymore, fixes Ticket #3858
Changeset #6336 (nate) Adding non-null association key fix in Model, and updating Model::isUnique() to account for current record, fixes [ticket fixed 38599, closes [ticket fixed #2032]
Changeset #6337 (nate) Fixing return value in Model::saveAll(), fixes Ticket #3852
Changeset #6338 (phpnut) Fixes Ticket #3829, Scaffolding and bake script has problems with tables that has underscore in it’s name
Changeset #6339 (phpnut) Fixes Ticket #3798, custom scaffolding file lookup paths inconsistent
Changeset #6340 (phpnut) Fixes Ticket #3862, set_time_limit(0) has no effect because of ini_set(‘max_execution_time’, 60 * 5); changed max_execution_time , 0. Since php 4.3 this is the default anyway
Changeset #6341 (phpnut) Fixes Ticket #3811, $_SESSION not found Fixes [ticked fixed 3823], Session not restarted after instantiating new SessionComponent? Fixes #3850, Configuration Session.start and SessionComponent::__active aren’t handle correctly
Changeset #6342 (phpnut) Fixes Ticket #3851, Acl component fails to check() if a permission is denied in action (*)
Changeset #6343 (phpnut) Adding test cases from [ticked closed 3810]
Changeset #6344 (phpnut) Reverting [] and [] this commit broke the working implementation. Closes Ticket #3810
Changeset #6345 (phpnut) Fixes Ticket #3854, Scaffolding is generating an id field with an empty value for auto_increment primary key
Changeset #6346 (phpnut) Fixing bug with scaffold and valid Session id check
Changeset #6347 (phpnut) Fixing bug with scaffold and valid Session id check in 1.1.x.x
Changeset #6348 (gwoo) updating View error handling for extensions, fixes Ticket #3795
Changeset #6349 (nate) Correcting parameter declaration in API shell
Changeset #6350 (nate) Fixing database drivers for UPDATE/DELETE changes, updating drivers to comply with model tests, most passing. Fixes Ticket #3794
Changeset #6351 (nate) Whitespace fixes
Changeset #6352 (gwoo) adding connection param to schema shell
Changeset #6353 (nate) Enabling alternate titles for PaginatorHelper::sort() links based on sort direction, closes Ticket #3865
Changeset #6354 (nate) Removing MySQL-specific schema code from core, improving support for PostgreSQL sequences, most tests passing

Google group topics

Why doesn't Find* return a group of model objects?

This topic has been discussed many times before, but Deane felt that it was required to ask yet again: “Why doesn't Find* return a group of model objects?“. He wanted to be able to work with his models in the view (!BAD DESIGN!), and was confused why he only got an array back from the find* methods. Gwoo replied, and I quote: “Speed, simplicity, clarity” and pointed out that Cake provide view helpers to work with the arrays in almost any way you can imagine, and that the models provide callback functions (afterFind, afterSave, beforeFind, beforeFind) to format your data.
Deane thanked gwoo for the reply, but “We couldn’t disagree more strenuously, and we think you’re wrong beyond belief in your reasoning, but we appreciate the response”…. didnt like gwoo’s reply at all.
Gwoo replied in a calmly matter that “Everyone is entitled to their opinion and their choice of frameworks.”
rtconner joined the discussion, offering a solution based on some old code by gwoo that would enable the models to return objects (StdClass, not models classes)instead of arrays.
Nick also joined the thread, backing up Deaen’s point of view (Cake is wrong, symfony lover is right) that its proper OO to use objects instead of arrays for the view data, but also reasoned that cake does indeed have the needed hooks and concepts to achieve Deane’s initial idea with a minimal effort. He explained that in a project he had created with CakePHP was that relationships (belongsTo, hasMany ect.) get more complicated with the OO styled approach, since the queries often fetched much more data than was really needed in the view. The combination of the controller didnt know wich fields the view required and the complex relation ships was in his opinion, not ideal at all. Their work a round was to create a “LazyData” class to handle it.
Robby Anderson dropped in his 2 cents, and agreed that the cake was isnt 100% pure OO, but that the concept of “having the view incapable of performing any meaningful business logic” is bad, and will sooner or later lead to an unmanagelbe code base.
Deane, the creater of the thread, posted a public apoligy to gwoo, explaining that he was fustrated at the time when he posted his previous post.

So, the summary must be that while some people dont like the design decission that CakePHP models return arrays instead of objects, others agree that its the right way to encapsulate the buisness logic in a correct Model View Control manner, and if you want to break theese convensions, its rather easy to do with minimal effort.

Passing Data To A Form

Travis asked how you are Passing Data To A Form. A bit unexpted (or perhaps expected given the flood of duplicate / newbie questions hitting the groups daily) nobody answered his question. The answer is pretty simple, and covered in any tutorial aviable on cakephp website AND in the documenation / manual.

1
2
3

function update($employeeID)  { 
     $this-&gt;data =  $this-&gt;Employee-&gt;findAllById($employeeID); 
}

The Show Is Back!

Jeff Loiselle aka phishy announced that the show is back. No replies, no thing, its sad… the show rocks !

I18n in 1.2 model validation message

Athies asked how does i18n in 1.2 model validation message work. His iniital attemp was to use the i18n method ‘__()’ in the model $validate array, but he was getting syntax errors when doing that.
Since PHP does not support useage of functions in instance delclarations its not possible to use i18n directly in the validate array.
Francky06l pointed at his solution in another google post i18n: static language references with __("My lang key", true) in models and controllers, and while the solution will work, its far from ideal when working with i18n.
A CakePHP google group regular, Dr. Tarique Sani, pointed out that the correct way to handle i18n validation messages was in the view, not at the model level. Amit Badkas backed up Tarique up and provided a simple example on how to do it:

&lt; ?php echo 
$form-&gt;input('username', array('error' =&gt; array( 
    'alphanumeric' =&gt; __('Username must contain alpha-numeric characters', true), 
    'between' =&gt; __('Username must be between 8 to 20 characters', true)))); 
?&gt;

Francky06l seemed to know that, his consern was the if he multiple views where the validation errors should show, it would be convenient to do it at model level.
Robby Anderson wasnt sure why you just couldnt do both, create the validation errors in the model, and wrap them in __() in the view.

And sure, that will work – but – you will loose some cake magic with that. The console application

cake i18n extract

will not add the i18n messages to the pot file automagic. Also, the i18n extract command will not even search your models for any i18n magic. It will only look in controllers and views. You can choose to call this a limit or a feature, but thats how cakephp has decided to do it, to enforce their paradime on how an application should be build and structured.

FormHelper Labels

Travis asked how it was possible to disable the automagic label in the FormHelper. Robby Anderson provided the correct solution for this issue, use ‘label’ => false:

&lt; ?php echo $form-&gt;input('Employee.name',array('label' =&gt; false));?&gt;

Using model objects in the controllers

Deane from earlier posted another question on Using model objects in the controllers. I dont really want to dwell much on this post, since its really attemp to take CakePHP in another direction than its supposed to. Deane clearly shows a lack of insight on how cakephp is supposed to work, and failed to provide any usefull examples that could show the group what he wanted to do.

Tags: Cakephp, english, weekly summaries

3 Responses to “CakePHP Weekly Summaries Issue #2”
Great overview, just like the first summary. Don’t feel too embarrased, you’re doing this as a courtesy in your free time

By Terr on Mar 4, 2008
I recently picked up a PHP project and decided to use CakePHP for it. I had used Cake before I moved to RoR. I must say the process of getting back into CakePHP was a painful one.

I can’t buy into the idea of returning arrays over arrays of objects. There are instance methods that are useful in any view – it’s not just about manipulating business logic. Nothing has to be manipulated in the view (that would be bad design). I often have counter cache methods, query methods, and other methods that BELONG in the model – not an external helper. They belong in the model because they are business logic, they are used in every other part of the application, and are used in formatting based on request (XML/JSON/HTML/etc). Having ‘helpers’ to do this is extremely limiting to actually accessing your data (not to mention extremely verbose).

For instance. I have a User. A user has one profile, and has many notes associated with it. On a display page, I would want to 1) check if they had any notes, 2) find out how many notes they have, 3) iterate over those notes and have the info attached to them. That first check, to see if they have any notes, could require business logic to decide which notes need to be displayed. Simply ‘creating more associations’ is a very poor way to go about this. My method, lets say $user->notes_count() is not something that is manipulated in the view, but is used to give me accurate results based on the relationship of the models (business logic).

Iterating over an array, and then using external helper methods to do this – is just a poor design (in my opinion). It should all be encapsulated in the model. The filters in the model should still be there – but I would disagree on some of their usages.

By Nate Klaiber on Nov 7, 2008
WOW! nice tutorial! that’s what I exactly need. You are explaining in such a simple and straightforward! why others can’t do it as you’ve done? may be it’s a talent… thanx a lot!

By Logan - Arbeitsrecht Rechtsanwalt Stuttgart on Jan 15, 2009

Cakephp.nu blog