Jonathan Snook has posted two methods for creating multiple validation sets in the latest version of your CakePHP application.

In CakePHP, you define how your data should be validated by setting parameters on the validate property of your model. In version 1.2, there is an on option that can be set on a specific rule that, when set, is either create or update. [...] Despite that, I developed a slightly different approach that allows for different validation sets to be specified and to be cleanly separated from each other.

He overrides the validates() method with his own in a custom model in one of two ways - having the script check for a validation set for the current controller or by specifying it directly with a validationSet property. Code for both methods is included.

DevShed finishes off their series looking a private, public and protected variables and methods in classes with this final look a private methods in PHP5 object-oriented programming.

It's time to leap forward and tackle this final article of the series, which will be focused on covering some additional aspects concerning the use of this kind of class method. In addition, I'll teach you how to utilize the "final" keyword, which is included with PHP 5, to prevent the methods of a specific class from being overridden by any subclass.

They work from a hands-on example to show how they can work with private methods (expanding a bit from last time) and how to use the "final" keyword to restrict any and all modification for a method.

DevShed continues their look at the use of the member visibility functionality PHP5 offers in its classes with this new part of the series, a look at the private property.

One of the most useful features that was introduced into the improved object model of PHP 5 is "member visibility." It provides PHP developers with the ability to specify the level of access each data member of a class will have in the context of a given application.

They review the other two keywords (public/protected) before venturing on to the use of "private" to protect, but allow access to, methods and properties in a parent class.

On the Ibuildings blog today, Harrie Verveer has posted about an interesting quirk he found when working with objects and references:

PHP is a loosely typed language. Most of the time this is very useful because you as a programmer don't have to worry about typecasting: it's done for you. However, on some occasions this can cause some unexpected trouble. [...] In this blog I want to point out what can happen if you try to access object properties by reference when the object is not initialized.

His example shows the problem when it tries to grab a value from an array in a non-existent object by reference. It results in a dyanamically created object (of that type) with an empty array inside of it. It only works when you grab it by reference, but he shares a tip or two about how you can prevent hard to track down issues like this.

In dealing with a little JSON encoding and objects in a project of his recently, Cal Evans bumped against a problem when he was encoding an object and moving it back and forth between the back and front ends.

The problem is simple, JSON encode a PHP object and send it back to the front end. Sounds simple and the last 100 times I wrote this code it was simple. This time, I was too smart for my own good. Here's the scenario.

He illustrates his problem - the "dropping" of properties somewhere along the way - with a sample class that encodes the object and sends it along. He missed one key bit of information, though. His protected array of properties wasn't getting passed back out correctly and we're in the resulting JSON message. A quick hack of a getProperties() function call made this problem a thing of the past.

Devshed continues their series looking at the use of destructors in PHP5 applications with part three, a method for keeping track of objects you've created during execution.

In this third part of the series, I'm going to show you how to retrieve some useful information about a specific object, including its properties and methods, prior to its being destroyed by the PHP parser via the implementation of a simple destructor.

Their new user class extracts the details about each of the objects right before they're destroyed via a call to get_object_vars and a loop to display the property and its value.

Evert Pot has posted about a library he's creating to integrate WebDAV support with PHP and make things simpler for those needing to access the shares.

I intend to make this library as easy as possible to use, without making it a black-box-like system. Focus will not be on everything WebDAV could possibly provide, but instead on the features that are actually supported by the operating systems.

His goal is to make it as simple as making a 'File' and 'Directory' class to interface with the remote system and has two things he's deliberating on as far as features to include in the library - support for the custom properties WebDAV allows and the ability to lock files and directories.

If you'd like to check out the current progress of the library, check out its page on the Google Code site (as well as this discussion group he's set up).

Continuing in their series looking at how to handle static data in a dynamic PHP application (see part one here), DevShed has posted the next piece in the puzzle, working with static properties in PHP5.

Provided that you already have an average background in using static methods with PHP 5, over the course of this second article of the series I'll dive a bit deeper into this interesting topic and show you how to take advantage of static properties defined inside a given PHP class, in this manner completing, at least basically, the implementation of static data with PHP 5.

They start by reviewing the functionality from the previous part of the series and build on it, creating static properties within the class (user data in this case) and how to use it in a mini app to set and display the information.

Wanting to test out a new way of doing things, Evert Pot decided to write up some tests using a Value Object style of data storage versus just in arrays:

In a lot of cases arrays are used in PHP to store object-like information, like the results of a database query. I do this a lot too, but I kind of want to change things around to make use of VO's. I feel this makes a lot more sense, since most of the application I build are heavy OOP anyway, and I get all the added OOP benefits, like type-hinting, inheritance.. well, you know the deal.

In his tests he creates an array of data, a value block of three "properties", looped 1000 times) and a block of three actual properties on an object. Between each, he's using the XDebug memory usage functions to check to see which uses less resources.

Overall, there's really not that much of a difference between using either of them. So, basically, it's up to you which storage method is the simplest for you to use.

Manfred Weber points out a new blog post from Jan Kneschke concerning the creation of and the idea of typesafe objects in PHP via doc-comments and the Reflection API.

From Jan:

I always disliked the way PHP handles Objects. There is no way to assign a type to properties. Validators have to be glued against the fields externally and you can't just generate a Object-Description (like WSDL) from a object either.

Because of this he's looked into an alternate solution - the typesafe objects. Since, by defauly, PHP's addition of object properties is pretty freeform, making things typesafe is a little difficult. His suggestion, though, uses a combination of comments in the code (declaring what the type of the property should be) and the Reflection API built in to PHP to "look back" at the comments and ensure the type of the property is correct. He even includes examples - a simple one about throwing an error, generating XML this way, and making safe encoded SQL statements.