Doug Brown asks a question on his blog today that is coming up more and more, especially on those programmers new to the language that don't quite get what frameworks really have to offer. Do you really need a framework for writing PHP?

The simplicity in using PHP sometimes acts against it. Since there are very few coding restrictions, developers tend to write a bad code. The answer to this is definitely to use a framework. There are various PHP Frameworks available today like Zend Framework, CakePHP Framework and CodeIgniter. They provide a strong organization for your application and follow the commonly used MVC pattern.

To help out those new to frameworks, offers a few things they have to offer that normal procedural/library-based development may not. These include maintaining code standards, attractive URLs and getting help when you need it from other developers using the same system.

Fred Wu recently posted some of his thoughts on using the Zend Framework as a developer in other frameworks looking to expand his knowledge.

When Zend Framework was first announced, the developers have promised us one thing: extreme simplicity. I was 'extremely' excited, but it turned out that it wasn't the case. Ironically, Zend Framework is the most difficult one I have come crossed so far. I mean, as complicated as Symfony is, it has brilliant documentation and an active community to back it up.

He also comments on the level of documentation the framework has ("the documentation is often outdated, sometimes inaccurate"), the Zend_Search_Lucene component, some of what he thinks are missing components that should be in a 1.5 release, and a last jab at the naming conventions.

Yet another PHP framework can be added to the lists already out there - Simplicity:

The Simplicity PHP Application Framework is an advanced, scalable and extensible PHP application framework to aid developers in creating high traffic, high availability Web 2.0 online applications. Integrating a solid MVC framework with some of the best Open Source projects around Simplicity aims to assist developers with any amount of experience in taking their applications to a new level.

As mentioned on the Ajaxian post about the framework, there's an Ajax admin console that lets the developer configure everything in their app including database info, creation of controllers and drop-in predefined actions.

Jeff Moore has posted and shared an interesting graph showing something I'd never thought about comparing one language versus another on - the number of keywords it uses.

Well, I like programming language comparisons, so how could I resist this chart (via) promoting the simplicity of the io language by pointing out how few keywords it has. The interesting thing about this is that Java and PHP are tied on this measure of simplicity with 53 keywords.

Though not too meaningful, it is interesting to see how the different languages stack up in the number of reserved words you can't use for anything else. So, does that mean that Perl is the list limiting?

In a new post today, Jonathan Snook takes a look at two of the more popular PHP frameworks (CodeIgniter and CakePHP), comparing and contrasting what it's like to work with each.

I almost fear putting this kind of post together as it's bound to pull the fanatics (in the negative sense of the word) out of the woodworks. Right off the bat, let me just say that I've tried to be as fair and honest in this assessment and I've tried to keep it just to the facts while interjecting what my preferences are.

I'm pitting these two frameworks against each other but there really isn't a clear winner. Each has its strengths and weaknesses and ultimately falls to what your preference for certain features might be.

He starts with the "why?" of it all before even getting into the code examples. When he does, it's all about models, views, the out-of-the-box features, auto-loading, and documentation. As he mentioned before he started, though, there's not a "winner" in this comparison. His personal choice, though, is CakePHP for simplicity's sake.

Cal Evans, of the Zend Developer Zone, is taking a different path than the large number of Zend Framework tutorials that he's seen out there:

Zend Framework looked like an interesting platform, but each tutorial that I read started out with explaining how to set up your front controller, and moved form there into writing an entire application. I am not starting any new projects, and have no need for that.

Instead, he's chosen to look a bit "behind the scenes" at what really makes the Framework tick and why it would be a good choice for any number of web applications out there. It's going to become a series on the ZDZ, so he starts it off right with a comparison between PEAR and the Zend Framework, specifically when it comes to error handling.

It's more of a compare and contrast kind of thing than a contest, but it does seem that Cal favors one's approach a bit more. Which one? Well, you'll just have to go read and find out...

On the Gentoo blog today, there's a note for those just getting into PHP - a warning of sorts for them to not read too much into the language.

Stuart Herbert advises those coming into PHP, both from other languages and as a first language, to not expect things to be overly complex. PHP is all about simplicity, and he reminds readers with a few points about objects in PHP.

His three points are:

• Classes and inheritence are not new to PHP 5
• Managing state between pages is very straight forward in PHP
• Folks who follow design patterns religiously are missing the point

And that's the beauty of PHP over many of the other tools that you have. If you want to write a system that's entirely object-oriented, you can. But you don't have to. You can create and use objects where they make sense, and you can continue to use global functions where they make sense. PHP's neutral philosophy gives you the freedom to just get on with it, and do what's right for your needs, your skills, and your tastes.

With all of the frenzy in the PHP community surrounding the issue of frameworks, more and more articles on the subject are showing up - including this new post from the Utah PHP User Group site, a look at CodeIgniter.

We all like the productivity of Ruby on Rails but most PHP frameworks don't seem to be quite right - some are too complex, some not stable enough, some not supported by ISP's, etc. I've now tried most of them and my conclusion was to follow the "stupidly simple MVC" series to just write my own code in a simple way but with some structure.

But I noticed several posters to that blog series mentioned Codeigniter as a great way to go with sort of the same philosophy. And today it was mentioned in Planet PHP. So I checked it out today, Wow! - it is really, really nice.

John Taber, author of the article, shares his opinions on the framework mentioning its simplicity and flexibility. He also briefly makes reference to a "simplicity similarity" to the Zend Framework.

In one of his latest blog entries, Justin has posted an article from Aaron Crane that talks about using PHP in large websites - some of the issues, methods, and suggestions that he's noticed over time.

The PHP scripting language has an enjoyed an enormous growth in popularity over the past few years. It benefits from being particularly easy to pick up, and from having been designed as a language specifically for producing webpages. This means that choosing PHP as your implementation language allows you to build a dynamically-generated webpage quickly and easily.

However, it is not clear how well PHP scales for use in larger commercial websites. This paper examines the issues in trying to do so.

He invesigates topics like:

• Separation of presentation from business logic
• Areas where PHP's initial simplicity can actually make things more complicated
• Using a team of developers to build a site

For each item, he looks in detail about what the topic is and how a manage/develoeper can get a handle on it. There are good and bad sides to all, but finding the right balance is key.

On Ivo Jansch's blog today, he takes the other side of things on the issue of fluent interfaces.

After Martin, Mike and Paul have demonstrated the usefulness of Fluent Interfaces, I'd like to take a look at the downside.

Ironically, Martin's original example already demonstrates the problem. (In the example) newOrder could be implemented in two ways: Create an order and return that new order, and Add an order to this customer and return the customer.

This can lead to confusion; the 'with()' method employs method b. If you think that newOrder returns an Order, and hence 'with()' is a method of the Order class, look at 'skippable'. Martin states that order lines are skippable. So what's in front of skippable() is an OrderItem. That means that with() must have returned an OrderItem. If that is true, then with() is a method of OrderLine too!

Confused yet? Well, be sure to check out his examples - they help to clear up at least the items mentioned above. His point is that, while the fluent interface does make it more readable, it can also make it more confusing - taking things down to such a simple level can sometimes eliminate some needed complexity to make things work properly (or as the user percieves "properly" to be)...