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.

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.

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?

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.

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...

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.

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.]]> Tue, 21 Mar 2006 07:03:45 -0600 http://www.phpdeveloper.org/news/4808 http://www.phpdeveloper.org/news/4808 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.]]> Tue, 07 Feb 2006 07:16:53 -0600 http://www.phpdeveloper.org/news/4583 http://www.phpdeveloper.org/news/4583 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)...]]> Fri, 30 Dec 2005 07:07:45 -0600 http://www.phpdeveloper.org/news/4514 http://www.phpdeveloper.org/news/4514 Mike Naberezny has his own take on the whole "simplicity" and "clean code" arguments between the different camps (PHP/Python/Ruby) and gives an example of a simple way PHP can handle your Secret Santa needs.

Today, I ran across Ruby Secret Santa. I couldn't help but think to myself, "That's sort of nice looking but wow, for a little thing like Secret Santa, how much overkill is that?" Here's the same thing in PHP, minus the database fetch (add it in two lines).

That's less than half the code. I think this is a fair comparison because it directly compares PHP to Ruby, without any "frameworks" or other middleware in between. Which one do you think is extremely simple?

I like how he puts it as well:

I think that Rails is a phenomenal tool, but it's tooling '" not a language. I am sure that great tools will come for PHP as well, and that PHP itself will always be a language that is both highly productive and high performance. Do you Yahoo!? ]]> Fri, 16 Dec 2005 07:40:48 -0600