ZillionBits-Its about number$ and te<h^0!0gy

I forget how I ran into this document now and can’t even tell you who the author is (hopefully they’ll step forward) but it’s an interesting read anyway: Aspects of the integration of two or more web applications (application/pdf). Found the link a while back, via one of the Gallery forums / mailing lists, thanks to a chance result searching for something entirely different on Google.

Anyway—memory loss aside—this is basically a short “research paper” written by one of the Gallery2 development team on how to do web application integration. In case you were wondering Gallery is a (perhaps the most) popular PHP image gallery application. Gallery2 is a complete re-write and was released last autumn (./ announcement here).

Returning to integration, this is area which has yet to be well solved IMO, either in PHP or other web platforms. The basic requirement often stems from “How do I provide my sites visitors a single signon to my forum / wiki / blog / gallery etc.?”. Read the rest of this entry »

Ran into web.py here, while it was still unreleased and got hooked by the API design and the comment Aaron made here

The third principle is that web.py should, by default, do the right thing by the Web. This means distinguishing between GET and POST properly. It means simple, canonical URLs which synonyms redirect to. It means readable HTML with the proper HTTP headers.

Since then web.py has been released with an initial reaction here—agree with those remarks so don’t need to repeat.

More interesting was hacking something together with it—a very simple wiki which took about 2 hours to get to where it is (below), while reading the docs and tutorial. Note this isn’t pretty code—the HTML in embedded directly, violating Aaron’s principle (didn’t want to have to mess with Cheetah as well), plus my Python skills are not the greatest but perhaps it makes a useful beginners example.

To install and run (Linux) to a file like wiki.py then do the following; Read the rest of this entry »

Just about a month ago Zend Technologies announced Zend PHP Framework in line with the Zend PHP Collaboration Project with the stated goal to offer a “de facto standard PHP Web application development and deployment environment”. Not much information has been made public by Zend, which caused a lot of discussion. Just here and there, involved persons piped up and delivered more or less useful information tidbits. Currently, Zend is working on a first version while working out the collaboration infrastructure and engagement guidelines.

While Zend is enjoying the attention in the PHP world, eZ systems determinedly worked on a very similar project called eZ components, of which a first beta version is to be released tomorrow Monday. Let’s have a closer look at what it has to offer and how it compares to Zend’s PHP Framework.

Design

Both projects seem to come as independent, loosely coupled components to reduce dependency, of which each user can choose for himself which ones to use. While eZ components shows no signs of designated application design, the Zcontroller and ZpageController components in Zend PHP Framework could foreshadow some sort of MVC framework.

Components

A list of eZ components will be available soon. Unfortunately it’s hard to compare it to Zend’s PHP Framework since there is only a small directory list available, which dates to October 24th. Nevertheless, first similarities can also be found: Standard components of a framework like database abstraction, exceptions, logging, templating but also input filters can be found in both projects. Read the rest of this entry »

Of all magic in PHP I probably like the __autoload() hook the most. It saves a good deal of tedious script inclusion calls and may drastically speed up your application by saving the parser from doing unnecessary work. Allthough it has been around since the release of PHP5, I haven’t found any convincing applications for it yet. Most of them follow the same scheme: Whenever an undefined class is being instantiated, a little __autoload() function tries to include a PHP file, which has to be named after it’s class:

< ?php
function __autoload($name) {
require_once(’classes/’.$name.’.php’);
}
?>


solution is inflexible and has some drawbacks. The most obvious one is the class name -> filename constraint. Furthermore, it implies that all class files are to be stored in one single folder. That is no option for projects with several hundert classes, naturally ordered in package directories. Overall, these implementations seem not quite mature but rather a proof of concept for __autoload(). This calls for a better solution. Read the rest of this entry »