I thought about this question for a while and have some thoughts on what it really means to know how to not suck at building things using PHP. In my never even remotely humble opinion I think the key is to understand what PHP is really good at.

He talks about how PHP had the early-adoption advantage at first with Apache, but how things have changed so much since then. Now, he proposes, PHP's popularity and usefulness is based on what it can do as a language without messing with frameworks at all. He's worried that, once someone picks up a framework, it'll become so ingrained that they won't know what "plain old PHP" can do (or how to work with it).

So my advice to Travis is that he should worry about learning to use PHP like glue and correctly identify the problems he is trying to solve NOW instead of worrying about the problems he might have to solve later. There will be time to fix your problems. Some of those will be solved by using tools that are not written in PHP, but PHP can still glue them together.

An application event is something that occurs which might be of interest to other bits of code. A standard event in most GUI applications would be a "click" event, but the sky's the limit and what events you define is really up to you. [...] The details can be provided by application-specific modules allowing you to keep individual requirements separate from your reusable code. Events allow you to attach a potentially unlimited amount of functionality without changing your core modules and components.

In his example, he shows how to create an event handler that is triggered when the user registers on the site. This event (CEvent) is then registered with the system and is attached via a call in the controller's "init" method.

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.

There's been a lot of buzz surrounding the use of frameworks for quite a while now and there are many great PHP frameworks to choose from. I was blown away by the simplicity and power of the base CComponent class in the Yii framework. [...] Every class in the framework extends from the CComponent class, which means that all subclasses work as components and can raise and handle events as well as be reusable and configurable. This packs a lot of punch for such a little class!

In this first post of the series, he looks at how this base class lets you work with class properties using the magic getters and setters. He includes some code showing how to set them up and how to use it to configure your object by passing in other component and their configuration.

Pagination is particularly useful when you are coding an application that interfaces with a database. A large dataset might have hundreds of possible results for one query, and pagination creates a much nicer user experience. In this tutorial, I'll use CodeIgniter's pagination library to show you how you can create a paginated list of results from a MySQL database. Along the way, you'll also see how to fix a problem with the pagination links that the library might produce.

He starts on the backend, creating a model to work with Country information and includes a "fetch_countries" method to grab the limited/paged list. Next up is the controller with an "example1" method that looks to the URL to see what page it should be on. The view is simple enough - just outputting the results back without worrying about how many to show.

The PatchworkUtf8 class implements the quasi complete set of string functions that need UTF-8 grapheme clusters awareness. These functions are all static methods of the PatchworkUtf8 class. The best way to use them is to add a use PatchworkUtf8 as u; at the beginning of your files, then when UTF-8 awareness is required, prefix by u:: when calling them.

In the README for the tool he talks about the functions included in the current release that match PHP's string functions as well as some additional methods like "isUtf8", "bestFit" and "strtocasefold". It relies on the mbstring, iconv and intl extensions being installed, and if they aren't, it falls back to other functionality (list of those methods included).

In my previous post Modern framework comparison I presented performance tests, which compared Ruby On Rails, Django and Symfony2. After recieving a feedback in comments I decided to run this benchmark one more time on my own laptop (instead of on my hosting). The reason was simple: enviroment was outdated.

There were some overall performance increases were seen, but some statistics were higher - the "time per request" for all of them grew, some by quite a bit. He presents these benchmarks with a caveat, though:

You should never choose framework based on benchmarks. Those shows them from one point of view, but there are plenty of other aspects, such as support, community, maturity, number of ready to use components.

Does it means that we have to make a choice between flexibility, customization, ease of testing and not having to copy and paste the same code into each application front controller? As you might expect, there is a solution. We can solve all these issues and some more by using the Symfony2 dependency injection container.

The Symfony2 DIC (DependencyInjection) allows you to create a container with the objects and settings that you want and inject that into the main "Framework" class for its use. He registers most of the components he's added over the series like the UrlMatcher, RouterListener, ExceptionListener, EventDispatcher and the Framework class itself. This is all stored in a separate file(s) and can be conditionally included based on your environment. He shows how to register a custom listener, add parameters to the DIC configuration.

If you were to use our framework right now, you would probably have to add support for custom error messages. Right now, we have 404 and 500 error support but the responses are hardcoded in the framework itself. Making them customizable is easy enough though: dispatch a new event and listen to it. Doing it right means that the listener has to call a regular controller. But what if the error controller throws an exception? You will end up in an infinite loop. There should be an easier way, right?

Using the "RouterListener" functionality, he sets up an "ExceptionListener" and points that to an error handling controller with its own "exceptionAction". This action takes the exception information and displays a "Something went wrong!" message along with the details. He also includes an update to the Response handling to allow for returning a string back from the controller instead of a Response object.

Composer is a command-line tool that helps you manage your application dependencies. It automatically fetches packages, resolves dependencies and is easy to configure. [...] Currently, Lithium doesn't provide Composer packages out of the box, but it's easy to write one.

He starts the post with an introduction to using Composer for those new to the tool, then moves quickly into setting up your "composer.json" file to pull in the Lithium updates from their github account. Additionally, he shows how to add a dependency for twig in the "require" section and pull it down at the same time (with dependencies).