In this new post to his blog Chris Hartjes mentions a "nifty little feature" that the latest version of the CakePHP framework has - dynamic models.

By default now, Cake will automatically use the AppModel class and create a unique alias to a database table if it does not find the file. This means that if you have a table that follows the Cake conventions, needs no validation, and has no associations to other tables, you don't even have to create the model file any more. Woah, talk about a serious time saver in some cases.

He also mentions a gotcha to keep an eye out for - misspelling the model name when you use it. It'll definitely break things. You can find out more about models in CakePHP from this section in their manual, The Cookbook.

A new entry has been posted to the PEAR blog with the latest minutes for the group's July 13th meeting.

Some highlights from the meeting include new/upcoming RFCs for package naming schemes, exception handling in PHP 5.3, and a vote on extending the current PEAR2 Policies. Heavy stuff, check it out!

You can check out the full notes here on the PEAR portion of the PHP.net wiki.

With more recent talk about namespaces in PHP 5.3, bloggers all over are tossing their comments into the discussion. Chris Hartjes is one of the latest with his thoughts on the point of the functionality.

I'm an outsider when it comes to tracking the going-on in the world of PHP internals. So, because of that, I'm not going to comment on the actual syntax of how namespaces will be implemented or it's impact on internals. That's not really important as far as this particular discussion goes.

He mentions one of the primary arguments for namespaces from the casual developer's perspective - keeping things separate and so classes can have the same naming as some of their cousins in other namespaces.

Tobias Schlitt has posted some comments on things recently said on PHP's upcoming support for namespaces - specifically on the ideas about naming classes the could conflict with PHP's own internal ones.

Namespaces are potentially coming in PHP 5.3 (does anyone believe?) and people start discussion about how they can even shorten their names from Abstract to aSomething and from Interface to iAnotherthing. I'm a fan of short names. [...] I agree with these rules and am of the opinion that class names must all above anything contain a semantic. Interfaces indicate what you can do with an object, while abstract classes model that different classes have a common base and can be used in the same mannor. And indeed you can add these semantics to names without using the terms.

He gives a few examples, things like Persistable, Configurable and Reflector.

The Zend Developer Zone has posted two more handy security tips - one concerning file/directory naming and the other about input validation.

From the first tip:

Don't rely on obscure names to keep your application safe. You should always check permissions, test for vulnerabilities with testing tools and keep an eye on your log files for suspicious activity. When designing your applications and web sites though, don't make it easy for bad people to do bad things. Don't use default or common names for your files and directories.

And from the second:

It's a sad fact of life but users are evil. Users want nothing more than to find a way to exploit your application. As soon as you let your guard down and start thinking "I'm only selling small stuffed animals so how evil can my users really be?" you've lost the battle.

You can catch up on these and the other previous security tips on this page on the Zend Developer Zone website.

As anyone that's worked with a programming language for a long time knows, you get to know the ins and outs of it pretty well. You get a good feel for how it all works and how feel confident in your skills with it. But what happens if you decide to move on and leave the relationship? Check out this take on just such a situation from the Yet Another Web Development Blog.

We've been together for about five years now. I've had a lot of good times and I've really enjoyed being with you. However, the more we work together, the more concerned I get about our future. I'm sorry, but you don't have the elegance that inspires me to want marry you. I think it's time we broke up.

Some of the reasons given for moving on is PHP's seeming identity crisis, consistency in function names/functionality, and performance issues that were just too much.

Despite being a bit anti-PHP, it's still a well-written piece. Check it out...

Keeping with convention - well, naming convention - is a good thing sometimes. Demian Turner thinks so and talks about one of many reasons he sees to follow a standard set in place for a while now - the PEAR naming standard.

By far the most convincing reason to use the file naming convention, which means that a class located in your include path like Foo/Bar/Baz.php is called Foo_Bar_Baz, is the ability to take advantage of PHP 5's __autoload magic method.

The __autoload functionality in PHP 5 is definitely one of the most handy, elegant single lines of code out there and I'd definitely vote for anything that will make working with it even easier. Demian also includes a few lines of example code to show the interaction between the function and the files with the naming convention.

Scott Johnson has created and posted another in his podcast series today, this time, he looks not at the development side of PHP - the actual code - but at the theory behind its development and best practices.

At the request of a listener to past podcasts, Scott created this one to share some of his experiences and findings along the path of his develoopment. Some of the items covered in the podcast include:

• package and library management
• naming conventions
• the seperation of UI and business logic
• code distribution
• using test harnesses

You can download the MP3 of the podcast directly from here.

Paul Jones has posted today about the release of the latest version of his Solar framework, version 0.20.0 alpha.

Exactly one month after the last release, I have uploaded version 0.20.0 alpha. There are lots of changes in this release, but the biggest news is that the page-controller now uses method-based actions (as opposed to file-based actions).

You can read the change notes here, but it's a really long list. If you want something a little more readable, with better narrative, you'll find it after the jump below. The new page-controller information is especially good. However, the narrative is quite long, so consider yourself warned. ;-)

For those that don't want to take the time to read through it all, he summarizes it into six different sections:

• Naming and Standards
• Class Name Changes
• Inherited Config File Values
• Adapter Configuration
• Locale Files
• Page-Controller Class

Each section has its own explaination of the changes made in (a bit) more concise manner. Be sure to check out the full notes to read up on everything.

As long as people "choose sides" when it comes to programming languages, there will always be articles like this to compare them. This time, it's a look at PHP versus another much-loved language, Perl.

The article takes a look at several different topics under this one umbrella, including:

• Arguments and return values are extremely inconsistent
• PHP has inconsistent function naming
• PHP has no lexical scope
• PHP has too many functions in the core

Obviously, they all seem to take a negative slant on PHP, but they do provide some content under each of the headings to back up their claims. They break out the contents of each of these examples to make comparison of Perl's and PHP's similar functionality easier. At the end, they also provide links to other resources and other posters illustrating some of the points they've shown.