Last year at the Symfony conference in Paris I have heard a really good quote: "There are only two hard things in Computer Science: cache invalidation and naming things" - Phil Karlton. I agree with it and it gave me a boost to keep evolving the concept.

He includes an introduction to the caching features of the framework complete with sample code showing first how to cache to the default file system and a more complex example that uses unique caches and page blacklists. Other features planned for the caching tool include edge-side includes, using Twig for templating and statistics recorded to a database.

In this article we will discuss some important features of Kohana, a promising and the sexiest community driven php framework. This article is pretty basic and intended to instigate those who are still not familiar with this framework. One of the problem with this framework is the lack of well organized documentation. Anyway there are many useful resources available and I have mentioned some of them at the end of this article.

He talks about some of the things he likes best about the framework including its HMVC (hierarchical Model view controller) support allowing you to cascade files down, allowing overrides at any level (good illustration here). He also talks about the scalability it offers and how, because of the HMVC functionality, you can split things up into interchangeable parts that can be pulled in based on the situation. Other features briefly mentioned include easy configuration, security and the exception handling and profiling.

For this example, we're going to allow our users to authenticate in one of multiple ways: e.g., against a database table, against an LDAP server, or by OpenID [1]. Zend_Auth already provides the necessary authentication adapters, so what we'll be concerned with here is how to implement all three systems without ending up in an FSUC situation.

He defines the code for the basic controller and a simple view that allows the user to select how they want to log in - email/password, username/password or OpenID. The model does all of the heavy lifting by letting the controller set the authentication type (strategy) and pulling in the correct Zend_Form instance along with its validation rules. Code is also included for the model and each of these.

Anyway, onto other matters. As you saw in parts 1 and 2, a bug part in having a successful transition from legacy app to CakePHP is having an environment that is well suited to the use of a framework. Having laid out the groundwork for that switchover, it's time to talk about the part of a refactoring or porting that is most difficult: separating your business logic from your display logic.

He talks about fat models, skinny controllers and flexible views with some code to illustrate each. This method makes the models do most of the work while the controllers are more of a go-between for them and the views. The views, then, are pliable enough to work with whatever data might be thrown at them.

In this tutorial I'll show you how to create a simple PHP script to cleanup a list of email addresses. As a web developer you have probably been asked to wash a list of emails from a manager or marketer some times. Here's the ultimate solution.

His script does a few things - removes duplicates, validates that the email address exists, uses pipes for communication and is as flexible as possible to work on most PHP distributions. You can download the simple script here.

The Zend Framework has a pretty good OpenID library. I was looking for a library written for PHP5 (strict), and this seemed like a good choice...

He mentions some of both sides of the argument - (the good) the flexibility of the library to work with different backend storage methods and (the bad) the requirements it has for the Zend Framework sessions system for authentication.

Designing a modular and component-based directory structure for your Web applications can seem like an easy task. If your system is small, it may seem logical to go with the simplest design possible, but if there's anything more time consuming and complex than developing a new directory structure design, it's trying to redesign an existing system that wasn't developed with growth in mind.

He breaks it up into a few different topics that can be applied where needed to keep the application in check:

• Consistency
• Scalability and Flexibility
• Single Application
• Multi-application
• Naming Conventions
• Versioning
• Proposed Structure

His list of four is:

• Doc Comments
• Flexible Parameters
• Use method Entry contracts
• Be Stateful and Refactor

The "Doc Comments" is pretty obvious, but some of the others need a bit more explaining. Being flexible with your parameters is more about requiring the least from a developer, "entry contracts" being the restrictions to let the developer know what you're expecting and refactoring commonly used functionality into a easy, single point of contact.

Now, consider the "average" PHP frameworks. They help you handle request data, manage your output, control app flow - essentially, extending PHP's inbuilt functionality. They are, therefore, PHP frameworks on the PHP framework. PHP provides a vast array (pardon the pun) of functionality out of the box. But when you want to do things your way, it gets out of the way, and this is really important when building anything beyond a simple database frontend.

He suggests that PHP is a "half framework" on its own, providing quick an easy methods and functionality to build up applications. He gives an example of Twitter (and really, who isn't picking on them these days) and how it probably could have avoided a lot of the issues it is seeing if it had gone with something a bit more efficient and flexible.

Be sure to check out the comments for some other great opinions from the community.

CakePHP is a rapid development framework for PHP which uses commonly known design patterns like ActiveRecord, Association Data Mapping, Front Controller and MVC. Our primary goal is to provide a structured framework that enables PHP users at all levels to rapidly develop robust web applications, without any loss to flexibility.

Among those on the list of handy tips for using the framework are things like:

• Static pages - Adjusting other data sent to the layout
• Viewing the SQL queries that are running behind the scenes
• Using bake.php
• Complex model validation
• Creating a model for a table that doesn't actually exist in the database
• Inserting multiple rows in succession