In this recent post to his blog Michael Kimsal asked about the usefulness of the __get and __set magic methods and the sort of code he usually sees along with it.

For a long time I've held that __get and __set in PHP were not all that hot - mostly because it's solely error handling. There's no way to deal invoke __get or __set behaviour for properties that are defined on a class. [...] For those who insist on using __get/__set, I *typically* see this [messyy] sort of style code. The effect is to cram a bunch of unrelated code in to the __get/__set overloading methods.

He suggests an alternative to the "cram it all in __get" approach - callbacks to other methods in the class to handle the different variable possibilities. In the comments there's other suggestions on how to get the same job done differently - mapping property values with __call, valid uses for getters/setters and a pointer to an internals discussion RFC about this same thing.

On the ServerGrove blog there's a new post spotlighting one of the Symfony plugins they think is interesting - the sfBehatPlugin, an interface into the Behat system for behavior-driven development.

Quality assurance (QA) is one of the most difficult things to implement around software development. Most of time it is left for the final phase of development and very often overlooked entirely. As many experienced web development teams already know, QA needs to be part of the development process from the get-go. [...] Behavior development/testing is just one aspect of quality assurance.

They briefly touch on the installation of the plugin (Symfony plugins are usually pretty easy to get set up) and link to the project's homepage for more references on some of the basics of using it to act as a browser, parse the response and use forms on a page.

On the PHP in Action blog, despite some agreement with Padraic Brady on his one behavior, one assertion method for writing unit tests, Dagfinn Reiersol still has his reservations.

Pádraic maintains that one assertion per test is a rule that should always be followed unless there is a specific good reason to break it. I prefer it as a guideline, as does Robert C. Martin in the book Clean Code. The reference is not intended as an appeal to authority to "prove" that I'm right. I'm just making the point that I think this reflects the current state of the art, which is not necessarily perfect, of course.

Dagfinn talks about behavior-driven development and illustrates how a two assertions could be combined into one but that the end result "isn't very pretty" - and that's just testing two proterties of a single object. Imagine what would happen if things got more complex.

Felix Geisendorfer has posted a new more helpful hints to the Debuggable blog for the CakePHP developers out there. Here's the most recent:

• Normalizing CakePHP model records
• Lookupable Behavior
• Cloud Behavior
• Akismet Datasource

Check out their PHP and CakePHP category on the blog for more great articles and tips.

Jonathan Snook has posted an update to a previous post about validating multiple input fields at the same time in a CakePHP application. This update changes the way the validation is handled and moves it over into a Behavior.

Using the new behavior is much like using the script as it was before. You can name the validation properties to include the action name and it'll automatically set that validation set as the default.

His behavior lets you define validation rules, both included in a default set and as callbacks. He includes an example of its use and the full code (all thirty lines of it) for the behavior itself.

In this new post to the blog.szajbe.pl site a dilemma is presented - CakePHP models are not working they way one would think they should.

In CakePHP you declare what models you're going to use in a controller by defining $uses variable. You can also define it in AppController to have a certain set of models available in every controller. However be careful when doing it because you may put yourself in an unexpected situation as I did recently.

As soon as he made his script include a 'User' model in every quest, his logins stopped working. His script errored with a "Database table sessions for model Session was not found" message and refused to work. Digging deeper, he found that CakePHP merges an AppController's $uses value with the SessionControler's values. One overrides the other and your 'User' gets lost in the shuffle.

Do you have a rational explanation for such behavior? I have none. It's very unintuitive for me.

In another behavior-driven development related post on his blog, Padraic Brady talks about mutation testing and a library he's put together to support it in PHP - PHPMutagen.

As I said in my previous entry I was thinking about how to write a Mutation Testing engine. The "braindump" was to use PHP's built in Tokenizer to break down a class file into digestible pieces which could be mutated, and then reconstructed into a mutated file. Once you allow for a working copy of the original source (let's not mutate the original!) it turned out to be a reasonable approach.

He's not releasing it just yet ("don't get too excited until I find some time to scan through it again") but he does share some sample output from his test run - one instance where all is well and the other where one mutant "escapes" and causes an exception.

The guys over on Sanisoft.com dropped us a line today to let us know about a new entry on their blog showing how to implement attach and detach behaviors in CakePHP models.

Behaviors are one of the best things that have been added to CakePHP 1.2, they allow you to add functionality to your models in a very elegant and modular fashion. They also promote a lot of code reuse. Perhaps a real life example would illustrate it better.

They show how to create behaviors that can perform a save() call on an image with the backend code doing all the hard work. They create the two methods - dontActAs and nowActsAs - to make attaching and detaching simple.

Felix Geisendörfer has officially released the latest version of his Containable Behavior for the CakePHP framework:

Sorry I've taken so long to get a new version of my Containable Behavior released, but believe me I've not been slacking this time. [...] In fact I'm releasing the new version as a BETA right now since I'm still not 100% satisfied with the result and not all features have made it in yet, but I felt the need for iterating. However, the new version should be a big step up from this initial one and I hopefully bug free.

The post includes both the code for the new version of the behavior but also several examples on its use. Improvements in this new version include better performance, new function (containments), support for dynamic field containments and different field containments.

Felix Geisendorfer is sharing a bit of his CakePHP knowledge with us today with this new post to his blog. It shines a spotlight on a feature of the framework - a behavior called "Containable".

For those of you who can't await this, here comes a little teaser in form of a behavior for Cake 1.2 called 'Containable'. Essentially it is yet another way to unbind associations from a model recursively on the fly. However, I think it's more powerful then all the ones released so far.

He lists his reasons (it's smart, it's for the lazy, etc) for using it before getting into a code example showing how, with the help of a bit of extra code) to make an object that can make making associations simple.