I like programming and listening to music. It helps set a pace for me to work. This little gem just popped in my head while I was listening to AC/DC:
Yes, I know. I'm awesome.
Build 6 of the Xyster Framework has been released. Tons of new features both in core and in incubator.
Please head over to the Xyster site and grab yourself a copy.
Build 5 of the Xyster Framework has been released. This version includes more features in Xyster_Container and various other slight modifications. You'll also find a bit more user documentation.
Please head over to the Xyster site and grab yourself a copy.
Note that this version of the framework uses features in Zend Framework 1.5 which hasn't been released yet. You can get a snapshot of ZF from their download page.
Congratulations to the Drupal team on their release of Drupal 6.0! There are many changes under the hood, but perhaps the most instantly useful of which is their native support for OpenID.
PHP 4 is end-of-life very soon. In addition to offering projects the chance to refactor and improve their application design, PHP 5 offers many things PHP 4 just doesn't. This series of posts will deal with things projects can get their fingers into that will benefit everyone.
The third: play nice with authentication.
Your application isn't the only kid on the block, especially if it's a single-purpose application like a forum or an issue tracker. Nothing is more frustrating than having to hack your application so my users don't have to login to different parts of my Web site.
Clay Loveless made a post in June of '06 stressing the stupidity of "loner applications".
You can remedy your application's isolation using one of two things: OpenID authentication or some kind of authentication plugin API or adapter.
Implementing OpenID is perhaps the lesser solution. Users would still have to put their OpenID address into each application on a site to login; it's not nearly as bad as having separate passwords, but still less convenient than a unified sign-on.
The preferred solution to this mess is to provide an API for others to write pluggable authentication modules and then pick which one is being used in a configuration somewhere. I applaud DokuWiki for their very simple and effective implementation of such an adapter. I also have experience with MediaWiki's plugin system, but don't get me started on the MediaWiki source code. Mantis has a decent start on an authentication plugin, but it still leaves much to be desired.
If you're going to start an authentication adapter system from scratch, may I suggest Zend_Auth? Adapters are a breeze to implement and Zend_Auth takes care of persisting a user's session. If you're using the Zend_Controller MVC, may I also suggest Xyster_Controller_Plugin_Auth? It gives you the ability to specify the MVC dispatch locations for login prompting, success, and failure.
Actually, adapters and plugins are a good idea for any software. If I have to edit a single source file for your application, you're doing a poor job at keeping extensibility in mind.
Build 4 of the Xyster Framework has been released. Most notable new feature: Xyster_Container, the dependency injection package.
Please head over to the Xyster site and grab yourself a copy.
Note that this version of the framework uses features in Zend Framework 1.5 which hasn't been released yet. You can get a snapshot of ZF from their download page.
Inversion of Control is one of those design patterns that once you "get it", you'll start seeing that it can be applied basically all over the place. It's the lesson of "tell; don't ask".
I've spent a good deal of time this weekend with the Xyster incubator; creating a Dependency Injection package called Xyster_Container based almost entirely on PicoContainer. The good: PHP method signatures are much more simple than Java's; only one constructor per class. The bad: PHP scalar method parameters are not typed, so you cannot use ReflectionParameter::getClass() on them. This first release won't support the LifeCycle capabilities or annotations, but at least annotations support is planned (remember, it's still in the incubator).
This Dependency Injection package will be used to replace/redo the Xyster_Application package. You'll read in Fowler's article (linked above) about the Service Locater concept, which was what Xyster_Application was intended to be. While the Locater might still be done, I think it's more important that application services can be injected into the classes that use them.
For now, read up on Dependency Injection. You'll wonder where it's been all your life.
PHP 4 is end-of-life very soon. In addition to offering projects the chance to refactor and improve their application design, PHP 5 offers many things PHP 4 just doesn't. This series of posts will deal with things projects can get their fingers into that will benefit everyone.
The second: stop using global variables; I mean it.
If there's one thing that really gets under my skin, it's the use of the global variable scope to store all kinds of things that just shouldn't be there. I've seen everything from lengthy configuration settings to global arrays for event hooks (I'm looking at you, MediaWiki). There are several reasons using globals is a bad idea, but I'll point out two important ones.
First, it's a vulnerability. The problem is that variables in the global scope are just that: globally available to be read from and written to by every line of code. A great security risk comes into play when sensitive information like usernames and passwords are available to your entire application or can be easily overwritten. What happens when an important global variable containing an array is overwritten to be a string? Whoops! The whole application just broke.
Second, it's sloppy. Putting values in the global scope so they can be accessed by your functions is hackish and ugly. It leads to problems with maintenance and debugging. If you have 500 functions that access a single global variable, you have to edit every last reference to it if you ever refactor your code. Consider what happens when you want to embed one application within another and they both happen to reference a global variable with the same name: mass hysteria.
What should you do, you ask? Matthew Weier O'Phinney made some good suggestions in an entry about Embedding Applications. He says use static properties or singletons to store your globally available settings; both good ideas. Let's go over two examples I brought up earlier and how to fix them.
Configuration settings should be loaded from and accessed through a configuration class; Zend_Config, PEAR Config, Solar_Config, you name it. You can throw exceptions for attempting to access a setting that isn't there, or just return null if you wish, but no more PHP notices about unset variables or array keys. Prevent changes to these settings except by actually modifying the configuration file. Store your passwords in an encrypted form. Place the actual configuration file outside of the web root. Make an instance of your configuration class available statically in a registry or by calling a static method.
Event hooks should be managed by a class with methods to add or remove hooks. Throw exceptions for an invalid event name or an unusable callback reference. Better yet: design a plugin API that implements the Listener or Observer pattern. You don't want someone inserting an invalid hook that breaks an entire system.
So long story short: use PHP 5's static properties or static methods to make available system settings and stop using kludgy globals.
Taking note of blog entries from Derek Rethans and Sebastian Bergmann about speed improvements to PHPUnit's use of Xdebug for code coverage analysis, I obtained the latest copies of each.
Running the full code coverage report for all Xyster tests used to take about 15 minutes on my modest hardware. The new versions of these libraries reduced that time to under 2 minutes. I was floored.
Well done, boys! Anyone running or using either library should definitely upgrade.
I applaud the efforts of the GoPHP5 campaign. They're getting commitments from lots of projects to adhere to minimum requirements of PHP 5.2; PHP 4 is end-of-life very soon. In addition to offering projects the chance to refactor and improve their application design, PHP 5 offers many things PHP 4 just doesn't. This series of posts will deal with things projects can get their fingers into that will benefit everyone.
The first: you have no excuse to support only one database.
PHP and MySQL for many years have gone together like bread-and-butter. Some applications still only solidly support MySQL. Nothing is inherently wrong with MySQL (shush, trolls), but not everyone can or will run it. I can't imagine many of these PHP applications are using super-proprietary MySQL features that can't be done with other systems.
Use an abstraction layer for your data access. PDO is a fantastic addition to PHP; it's been stable and in the core distribution for a good two years. If you have the extensions for each system, PDO can out-of-the-box support MySQL, Sqlite, PostgreSQL, MS SQL Server, Oracle, and recently DB2. In the Zend Framework, Zend_Db is a great tool as well. It's fast, well-thought-out, has many convenient features, and provides some more abstraction than PDO does. For instance, listing all the tables in a database, describing a table, and performing limit/offset queries.
All that's left to you the application developer is writing the SQL for creating your tables in each database system. As far as I'm concerned (Yes, and my opinion matters), you should support the "Big 4" (MySQL, PostgreSQL, MS SQL, Oracle) out of the gate; these have the widest install base.
Lastly, since you're going to the trouble of using such a data access layer, make sure you take advantage of value binding. Binding your values to placeholders in the SQL statement greatly reduces the risk of SQL injections. It also lets the DB worry about how to escape the value.
So stop being database system elitists. You'll have a wider and happier user install base if your system supports a few databases.
The second build of the Xyster Framework is available for mass consumption.
Please head over to the Xyster site to grab yourself a copy.
The API docs should be current, but the user manual won't be up until tomorrow or Friday.
