If you are one of those folks who have been using PHP and nothing but PHP for a long time you will be hard pressed to find an alternative. PHP is, after all, one of those things that are “easy to get into, but difficult to get out of”. PHP lures you in with its forgiving nature, vast library of pre-built extensions, ease of deployment and just plain “instant gratification”. It’s easy to forget that there are other languages for server-side programming/scripting.

More Tools for your Toolbox

When I was teaching CS classes back then, I always told my students never rely on a single programming language and never tie yourself to a single platform. I have always stressed the importance of learning more than one programming language and making sure that whatever you do, do it cross-platform if possible. By not limiting yourself to one language or platform, you will be able to develop solutions using the right tools for the problem at hand.

The following is a short list of programming languages that I have used in the past. These are my “bread and butter” languages in addition to PHP. These are also the reasons why I found it easy to ditch PHP. If you have never used any other programming language besides PHP, perhaps you should take a look at what else is out there.

One Interface Behind Them All

In theory, you can use any programming language to do server-side programming. You read that right: you can use any programming (or scripting) language. You can use C, C++, Fortran, Haskell, Java, Lisp, Lua, Perl, PHP, Python, Ruby, and so on. You can use whatever you want, as long you are able to receive input and send output via the Common Gateway Interface or CGI.

Server-side programming/scripting essentially involves two basic operations:

1. Receiving and acting on a request;
2. Sending back a response.

CGI acts as a bridge between your web server and your server-side program/script. When your web server receives a request and it sees that request as a request to execute a program/script on the server, it will set up everything that is necessary to run your program/script. It then runs the program/script, captures its output, if any, and sends it back to the client who issued the request. In Unix terms, any program/script that can take input from stdin and send output to stdout can be used on a web server that supports CGI. This is an overly simplified description. If you wish to learn more about CGI, use “the Google”.

Because the server runs the CGI program/script as an external process to handle each request, this means that there is an overhead for each request. To boost performance, modern web servers have come up with ways of eliminating or reducing the overhead from external process creation. For instance, Apache allows you to create modules that act as filters and handlers for requests. In most cases, PHP will have been installed as an Apache handler on your server which embeds the PHP interpreter in the running Apache process, eliminating the need to create an external process to run your PHP script. There is also an extension to the CGI standard called FastCGI which takes a different approach. FastCGI runs several instances of your program/script as long-running background processes. The webserver then connects to these processes whenever a requests requires the use of CGI, sends the request and collects the response and sends it back to the client.

Of course, these days you care less about the details and worry more about what your program/script does.

Is it “Programming” or is it “Scripting?”

At the heart of it, programming is programming and scripting is programming using a scripting language. In the early days, it’s easy to differentiate between “scripting” and “programming”. Scripts were written using “interpreted” programming languages which typically ran inside another program (e.g., CAD with Lisp scripting) or a stand-alone interpreter. “Programs”, in the original sense of the word, were written using “compiled” programming languages.

These days, the distinction has been blurred with the advent of compiled programming languages that are run using an interpreter. Java is just one example of this. You write your Java program and then compile it into machine-independent byte-code which you then run using a Java virtual machine or JVM. A JVM is essentially an interpreter but these days, we also have the so-called JVM with Just-in-Time compilation which maps machine-independent byte-code into native instructions for the CPU running the VM.

It’s all become so confusing these days with all the recent developments in VM technology. The distinction between “scripting” and “programming” has eroded. Personally I just prefer to call it programming. So from this point onwards, I will simply use the term “programming” to refer to “scripting” as well and “programs” to refer to “scripts”.

One more thing: Knowing how to write HTML and CSS does not make you a programmer, so please stop calling yourself a programmer or “coder” if all you know is HTML and CSS.

The Duct Tape of the Internet

Let’s begin with the grand daddy of server-side programming: Perl. Created by Larry Wall in 1987, it has evolved into a true, general-purpose programming language. It was developed primarily to automate system administration on Unix systems. It began to gain popularity in the early 1990’s as a convenient way to write CGI scripts. PHP can trace it’s origins back to a CGI script written by Rasmus Lerdorf using Perl. That’s right, a scripting language begat another scripting language. You can see shades of Perl in PHP, the most visible is the use of the $ symbol to start a variable name.

Perl may come across as a quirky, cryptic language to some. It has also been the butt of jokes in recent times with the advent of newer (and sexier) programming languages. The Perl mantra TIMTOWTDI (there is more than one way to do it) is both a blessing and a curse. Take printing a progress bar for example. As one person found out by asking the Perl monks, TMTOWTDI. But make no mistake. Perl is a very powerful language, with a friendly community and a huge library of pre-written modules.

The standard Perl installation comes with the CGI module which allows you to get up and running with CGI very quickly. You can use Perl to write a simple CGI script without using the CGI module. However, using the CGI module frees you from having to deal with a raw CGI environment. It also gives you with useful functions for handling query strings and forms, URL escaping, and error handling.

It also comes with a standard for database interfaces and drivers (DBI and DBD). DBI will usually come pre-installed along with commonly used database drivers. If you are familiar with ODBC or if you have played around with PDO, the Perl DBI is similar in spirit. It provides you with a consistent interface for database access and more importantly, it gives you prepared statements even if the underlying database does not support it.

More importantly, most virtual hosting shops support already support Perl in addition to PHP. You will probably have two options, depending on your hosting provider. First option would be to write your programs as just plain CGI programs and upload them to a special directory on your account. Second option would be to write your program to take advantage of mod_perl if it is installed by your hosting provider. mod_perl not only allows you to write CGI programs, it also allows you to create Apache modules using Perl.

Over-Engineered Beyond Help

Next up we have the programming language that no self-respecting software “engineer” can do without: Java. Although it has all the required facilities needed to write CGI programs, if you must do something in Java, you should do it properly. And the proper way of server-side programming in Java is to write a Java Servlet. In order to do that, you need to run it inside a Servlet Container such as Apache Tomcat.

Java already has database connectivity covered with its standard JDBC. Odds are that your servlet container can also run JSP’s which allow you to embed Java code in your markup. Your servlet container then takes these JSP’s, compiles them into a servlet when handling the first request and uses the compiled servlet to handle subsequent requests.

As you have probably learned by now (or not), it is better to separate your program into distinct areas using the Model-View-Controller paradigm. Java supports this out of the box. You have POJO’s (plain old Java objects) to use for your model. The servlet serves as controller. JSP provides you with the view. Once you have the basics nailed down, it’s all very simple onwards. Or not…

As your program grows in size and complexity you will find the simple MVC approach using POJOs, servlets and JSP’s become unwieldy at best. You will be looking for a better solution. Java has a standard for developing large scale web applications too. J2EE is a collection of standards that encompass everything you need to develop large scale web applications and service oriented applications (SOA’s). Newbies will probably be overwhelmed by the amount of complexity involved in developing and deploying large-scale apps using J2EE. It has more acronyms than a bowl of alphabet soup. Once you’ve finished wading through your acronym soup, prepare to swim in XML tag soup. Almost everything in a J2EE server is configured using XML. But then again, developing and deploying a large-scale J2EE app was never meant to be a job for a lone developer and there are tools you can use to tame all that XML.

As for hosting your Java apps, typically you need to find a specialized hosting service of which there is no short supply.

Ooooooh! Shiny!

Then there’s Ruby. First released to the public in 1995 by Yukihiro Matsumoto, it was an obscure programming language from Japan that exploded in popularity in recent years (due to a well-marketed web programming framework). As one fellow so succinctly put: “Ruby is the language for trendy, non-conformists.”

Ruby by itself is a very capable language with a large set of libraries included as standard. The CGI library is one of them so you can also get to writing server-side programs in no time. Like Perl and Java, it also comes with a standard library for interfacing with databases.

I tried Ruby some time early last year but I find its reliance on on begin and end to be a major annoyance at best. That’s the reason why I hated programming in Pascal and VB so much. Come on, if braces worked for C, C++, Java, Javascript, Perl, PHP, etc. why bother using whole words to delineate blocks of code? Another sticking point, at least at the time, was performance. For small one-off scripts, it’s pretty decent. However, for larger more complex programs which are spread across several files, performance really sucks! The time it takes to launch the interpreter, byte compile your code and run it was simply unacceptable for me. If you’re going to use Ruby for CGI programming, use FastCGI or some other way of keeping a cached copy of your byte-compiled code in memory.

With those two aside, I find some features that make Ruby hard to resist. There’s “monkey patching”. Ruby classes are open classes. This means two things: you can spread class definitions across multiple files and you can modify built-in or standard library class behavior. Being able to spread class definitions across files helps to make your code more manageable as it grows in complexity and size. By modifying behavior of built-in or standard library classes you’re able to create semantics that are more suited to the job at hand. This can also be a problem, especially if your program is reliant on third-party libraries, as it is possible that the modified behavior is not what you really want. But when done carefully, it can extend the usefulness of existing classes (like to what Mootools does for Javascript).

Ruby also makes it relatively simple to map data from a text file or database record into a dynamically generated class at run-time. This proves useful in creating ORM’s (object-relational mappings). Most Java ORM’s use a clunky approach glued together with unholy amounts of XML. Ruby makes it easy by providing the facilities necessary as built-ins.

Another great feature is class composition. This is similar to the concept of interfaces and mixins in other languages. You define a set of methods and properties in a module. When you need them in your class, you simply include the module.

As for finding hosting providers that support Ruby, thanks to a popular web programming framework, most hosting providers now support Ruby in addition to PHP and Perl. Just like Java however, you can get better bang for your buck by going with a specialized Ruby hosting package.

Batteries Included

Now we come to my programming language of choice: Python. While using whitespace to delimit blocks of code may seem strange to those who come from the “bracketed” programming languages such as C, Java, Perl or PHP, it actually makes your programs easy to read by default. You don’t need to remember any silly coding and indenting conventions. As long as you use a consistent means of indenting your code (4 spaces is recommended), you are pretty much set when it comes to readability. It was a bit uncomfortable at first but blocks delineated by indentation sort of grows on you eventually.

With that single “unusual” quirk aside, Python has all of the tools you need to get started with server-side programming: “Batteries Included”. Simply import the cgi module in your code and start plugging away at your program. However just like in Java, there is a standard way of doing things and the standard way of server-side programming using Python is through the use of WSGI. Python’s WSGI is similar in spirit to Java’s Servlet specification. It defines a standard way of writing programs that have to interface with a web server using a request-response model. It takes the server’s execution environment, the client’s request, and the server’s response and packages it into one coherent specification.

One more thing that I like about programming in Python is that your program sort of describes itself. You spend less time writing descriptive comments as to what a section of your code does, unlike other programming languages. Chances are that you can write a Python program now without any documenting comments, come back six months later and look at your code and you will still be able to read and understand what it does.

Performance-wise, Python has consistently outperformed PHP and Ruby as of late. Python programs are compiled into byte-code before it gets executed by the Python VM (interpreter) just like Java. However, unlike Java, there is no explicit compilation step necessary. Unlike Java, Python can run your code regardless of whether or not it is in the byte-code compiled form. Your byte-compiled Python code essentially acts as an on-disk cache for the VM. When you first run your program, the Python interpreter will byte-compile your code and if it can, it will write the byte-compiled code into a file with a .pyc extension. The next time you run your program, the interpreter will check if there is a .pyc file present. If found, it will check to see if your source file is newer than the .pyc file. If your .pyc file is up to date, the interpreter skips the byte-compilation step and runs the .pyc file instead. If your source file is newer, it will byte-compile it and try to write it to disk. This is another reason why I prefer Python over anything else. I can distribute just the .pyc files without the .py source files. I am all for “open source” but there times when you just don’t want clients to be dicking around with your code.

As for libraries, chances are good that the standard Python installation already has everything you need. Python also comes with a standard for database interfaces called DBI, which like its Perl counterpart, provides you with a consistent interface regardless of what database you are using. It also provides you with prepared statements which can be emulated in the driver in case your database does not support it.

Just like Ruby and Java, you are better off going with a specialized Python hosting package if you are going to do WSGI. If you only need to write CGI programs in Python, then many hosting providers already support Python in addition to Perl, PHP, and Ruby.

So there you have it. I hope this goes to show that PHP is not the be all and end all to programming.

a

Reading the IRC chat log that lead to the “backslash as namespace separator” decision just affirms my impression that the PHP language is in the hands of neurotic, crack-smoking monkeys. Well except for a few people like Dmitry. Apparently there are two problems with “::” that prove too difficult for them to solve:

1. There are some modifications needed for “::” to work properly but these modifications will break existing code. I would say, what the hell! Break existing code! PHP6 will break existing code anyway. But no, they also want namespaces in PHP5 so there!

2. The engine can’t detect ambiguity without calling autoload. It introduces the so-called “autoload bomb”. Apparently, calling autoload once for each namespace as Dmitry suggested is “impracticable[sic] because it relies on the programmer to know when ambiguity arises”. Huh?!? Forgive me but isn’t it the job of the compiler/interpreter to detect such an ambiguity and tell the programmer???

So instead of fixing the fundamental problems with the engine, they want to use the band-aid solution of adding a different syntax for namespaces. Oh wait, maybe it’s because the engine is so horribly designed that it’s impossible to write in sensible changes without having the whole thing fall apart completely?

I have been fighting so hard to keep this from swaying me away from PHP. I have lived through and worked around the inconsistencies and quirks of the language, but this “backslash as namespace separator” crap is the last straw. It sucks that I have to maintain a lot of PHP code but from this point onwards, I will no longer use PHP for new projects.

a

So, they want to replace the de facto standard namespace separator “::” with “\”. That’s right: replace double-colon with a backslash! Why? It’s because “::” is already being used in class method invocations and it will cause problems during parsing. Consider the following:

class Lol {
    public static function whut() {
    }

namespace Lol;

function whut() {
}

Elsewhere:

Lol::whut();

When you write Lol::whut(), which one are you talking about? Is it the static function in the class Lol? Or is it the function in the Lol namespace? I can think of a few solutions to this very simple problem besides changing the damned separator character.

1. Throw an exception during parsing/compilation and complain that the symbol Lol has already been defined. Ideally it should say something sensible like: “Class name ‘Lol’ defined in main namespace conflicts with existing namespace definition ‘Lol’ found in FILE, line LINE.” For dynamically generated code, throw a runtime error and halt program execution. This is how C++ handles it, I can’t see why PHP can’t do the same. I would prefer it this way because I don’t want some moron programmer who is using my Lol library to write a class named Lol in the main namespace!

2. Throw an exception like in #1 but make it a non-fatal exception and just let the class method defined in the main namespace take precedence. Or even let the function in the namespace take precendence. Do it one way over the other but tell the programmer that there is a problem with his code!

3. Force Lol::whut() to resolve to the class method and ::Lol::whut() to resolve to the function defined in namespace Lol. Or vice versa.

I would really love to see arguments leveled against the 3 solutions above because changing the separator character is just plain stupid. Oh, and it’s butt ugly too. Sure it’s just in RFC but if this sort of stupid shit makes it into PHP6 then it’s time to say bye-bye PHP… It looks like they have their hearts set on using backslash as the namespace separator and it’s pretty much set in stone.

On a side note, when I was reading the RFC I had to take a second look at the date to make sure that it does not say April 1, 2008. They were considering the “smiley” as a namespace separator?!? Surely you jest!

a

Not satisfied with the PHP5 frameworks I found I decided to write my own (again). I looked at one particular candidate — [Picora ™: PHP Micro Framework][picora]. It’s small and focused on doing one thing: provide an MVC framework for PHP. While it has both qualities that I was looking for in an MVC framework there are a couple of issues that I found:

• it currently lacks an ActiveRecord implementation.

Note that the model() calls use a PHP ActiveRecord implementation which is not part of Picora, substitute with your own database logic for the time being.

• it makes the same (IMHO) mistake as CakePHP and Rails in that actions are mapped directly into methods in your Controller class without giving you the option of delegating it to a separate class. While there’s nothing wrong with this, I found that having all your actions in one big file becomes unwieldy when your project grows. Which was why I came up with [a modified action mapper for CakePHP][cakephp-sucks01].

So, for now Picora ™ doesn’t quite cut it for me yet. I began writing a new framework, based on some ideas I had from a year ago as well as taking a lot of inspiration from Django. I am writing the model class hierarchy based on Django’s excellent ORM. This will also be my first large project written using PHP5. Needless to say it has been pretty frustrating to find that PHP5 lacks namespace support. I was left wondering, “With PHP5, they practically went out and copied Java and yet they forgot to implement namespaces?!?”.

I did a search on Google for “php namespace support” and what I got was a depressing state of affairs for this important feature. It turns out that at the time, PHP5 namespace support is not a simple thing to implement and one of the major issues is the namespace separator. Maybe this is a testament to the fact that the PHP language is horribly broken an a multitude of places? Or maybe it’s because “design by committee” does not work? I found [one particularly entertaining post about the issue][shalosh] from 2005 and [a more recent posting][phpnamespaces] citing a [patch that implements namespaces for PHP6][phpnamespace-patch]. It looks like [namespace support will be in PHP6][zend-weekly]. I can only hope that this will be backported into a point release for PHP5.

Among other things I would like to see in PHP6:

• Closures or real anonymous functions at the very least. No, create_function() does not count!
• Inner classes.
• Inner functions.
• Make built-ins like include(), include_once(), require(), and require_once() throw exceptions in addition to their original behavior. But it would really help to do away with the old *_error_handler() way of doing things.

These are just some of the features that I wish was in PHP, ever since PHP4.

[picora]: http://livepipe.net/projects/picora/ “Picora ™: PHP Micro Framework” [cakephp-sucks01]: http://abing.gotdns.com/posts/2006/cakephp-delegating-actions-to-separate-classes/ “CakePHP: Delegating Actions to Separate Classes” [shalosh]: http://blog.phpdoc.info/archives/27-+1-for-Shalosh-Nekudotayim.html “Shalosh Nekudotayim” [phpnamespaces]: http://www.gravitonic.com/blog/archives/000418.html “PHP Namespace Support” [phpnamespace-patch]: http://news.php.net/php.zend-engine.cvs/5894 “PHP6 Namespace Support Patch” [zend-weekly]: http://devzone.zend.com/article/2336-Zend-Weekly-Summaries-Issue-348 “Zend Weekly Summaries”

a

Of course, hosting for these patches continues as well as my ThemeableView class which some CakePHP users out there found useful. If anyone else is interested in taking the reins for this class, please feel free to do so. No need to contact me or anything, but a trackback to this post would be nice so that I will know who is currently maintaining this class. This will allow me to direct them to you for any updates that you may post.

On another note, the project that has been taking much of my time lately is a new website for posting free online classified ads for cars, trucks, and bikes. This website is currently US-centric. We have plans to extend worldwide if all goes well with the current setup. So, if you’re in the US and you wish to sell your vehicle, or if you’re looking to buy a preowned car, truck, or bike check out PreOwnedCar.com. If you know someone with the same needs, please tell them about this site.

We are also currently in the final design phases for PhilWeavers Version 4. I am currently divided between doing this new version using Django as a base or simply going back to the drawing board and creating a new PHP5-based framework. We’ll see how this pans out in the later stages of development.

a

It makes me wish CakePHP offered more when it comes to object-relational mapping. How I wish it was as simple as defining your models and running php cake/scripts/bake.php syncdb. CakePHP does it the other way around: you create the database first and then use cake/scripts/bake.php to create your models and views.

I found that Django’s way of doing ORM is significantly faster. You specify your models as Python classes using Django’s modeling API. You run python manage.py syncdb and Django takes care of generating the correct SQL for your database backend. It takes model relationships into account and also generates the correct foreign key constraints. Beautiful!

A similar system should also be possible to implement in CakePHP. I’ve been having a few ideas of how to go about it and hopefully, I can find the time to do them as an add-on to CakePHP 1.2.x (and hopefully, someone else is already working on the same thing).

Here is what I imagine it would look like:

class User extends MetaModel {
    var $username;
    var $password;
    var $lastname;
    var $firstname;
    var $is_active;
    var $is_staff;
    var $is_admin;
    var $created;
    var $updated;

    function __construct() {
        $this->username = FieldFactory::CharField(’Username’, 32, IS_PK, IS_REQUIRED, NOT_NULL);
        $this->password = FieldFactory::CharField(’Password’, 64, NO_INDEX, IS_REQUIRED, NOT_NULL);
        $this->lastname = FieldFactory::CharField(’Last Name’, 64, INDEX, IS_OPTIONAL, NOT_NULL);
        $this->firstname = FieldFactory::CharField(’First Name’, 64, INDEX, IS_OPTIONAL, NOT_NULL);
        $this->is_active = FieldFactory::BooleanField(’Active’, IS_REQUIRED, NOT_NULL, false);
        $this->is_staff = FieldFactory::BooleanField(’Staff’, IS_REQUIRED, NOT_NULL, false);
        $this->is_admin = FieldFactory::BooleanField(’Admin’, IS_REQUIRED, NOT_NULL, false);
        $this->created = FieldFactory::DateTimeField(’Created’, NO_INDEX, IS_REQUIRED, NOT_NULL);
        $this->updated = FieldFactory::DateTimeField(’Updated’, NO_INDEX, IS_REQUIRED, NOT_NULL);
    }
}

FieldFactory would have static methods for instantiating the correct field objects for each type. It would also have methods for generating constraints for implementing many-to-one and many-to-many relationships. I think a new model class is required to be able to do the additional magic without changing the current API.

I haven’t thought about how to implement the analogs of Admin and Meta inner-classes yet. I think those can be done as fields in the model, maybe $this->__meta and $this->__admin. As for QuerySets, Q objects and other classes in the Django DB API those are pretty much doable under PHP.

For SQL generation using the models, I imagine the backend will first load all the model classes found. Then models extending the MetaModel base class are instantiated and introspected to generate the correct DDL statements in database-specific SQL.

This is not a trivial undertaking and will take a lot of planning and thought. Model introspection and ORM should use as much of the existing CakePHP API as possible.

One last thing, if you are working on a similar system for CakePHP leave comments below. Remember: DRY.

a

CakePHP modifications will continue once I finish my current project and once CakePHP 1.2.x.x gets sorted out.

It’s interesting to see the direction that CakePHP 1.2.x.x is currently taking. It seems that most of the functionality I’m am currently working on with my modifications for 1.1.x.x is in the works for 1.2.x.x. Here’s the short list of features that I really need:

• Lazy-loaded models (already backported into 1.1.x.x) — This was one of the major gripes that I had with CakePHP as it loads class files for models that you do not even use. This feature increases performance and reduces memory footprint for very large applications with a large number of models.

• Validator classes — This new feature allows for more complex data validation while maintaining the DRY principle. I never liked the idea of using simple regex strings for data validators. What if I wanted to do more complex data validation? (e.g. query a user database if a username already exists) In my old framework, I used validator classes when handling form data. Each form field has its own validator chain and can include as many validator objects as it needs.

• i18n and l10n — Because it’s a big world out there and not everyone speaks English. There is now the beginnings of an internationalization and localization API in the framework.

• User Authentication — Although it’s not clear yet where this is going, I expect that there would be an extensible authentication framework with support for both simple authentication (username+password) and challenge-response authentication (username+password+challenge token).

Now, if only they could throw in a “standard” regression and unit testing framework and add a generous smattering of metaprogramming constructs into the mix…

I have also been following a very interesting discussion with regards to [using the built-in system ACL in limiting user access to data][acl]. The current ACL system built into CakePHP uses what’s called MPTT or Modified Pre-ordered Tree Traversal to navigate through a network of ACO’s and ARO’s. I have made my own MPTT implementation for the object system in my new CMS.The code for this is not for the faint of heart. Yet, the flexibility that you end up with is well worth the effort.

The current discussion on the list about ACL’s made me look deeper into my MPTT implementation. From what I can gather, it will not scale very well as the number of objects increase as it uses a recursive algorithm when reordering the tree traversal data. So now I’m off to look for a better implementation…

[django]: http://www.djangoproject.com/ “Django Project Home” [acl]: http://groups-beta.google.com/group/cake-php/browse_thread/thread/263d3ffd6fb7533d “Using ACL to limit access to data”

a

In [part one][part-1], we went through the basics of the Singleton design pattern. We ended up with two classes:

• An Object class that we can use as a base for our classes. This class takes care of object construction through a __construct() method as found in PHP5.

• A SingletonInterface class that we can use as a base for Singleton classes. This guarantees that we have a consistent interface for all Singleton objects in our application.

Simulating Namespaces

One of the important things that PHP4 (and PHP5!) lacks is the concept of namespaces. If you have ever programmed in C++, C#, or Java you will be familiar with the concept of namespaces. For those who are not familiar with it, a namespace can be thought of as a named boundary within your program that can contain variables and functions. In other programming languages it is also possible for a namespace to hold classes and even other namespaces. One of the main reasoning behind the concept of namespaces is to prevent naming clashes between software libraries.

Using a namespace, you can create global variables under one namespace without having to worry about another global variable with the same name under another namespace. The two global variables are treated as two different global variables even though they have the same name.

Now that we have a workable implementation of a SingletonInterface, it’s time to put it to use. One of the most useful applications of a Singleton in PHP4 (and PHP5) is to create a namespace to place our “global” variables under. For example:

class MyGlobals extends SingletonInterface {
    var $_properties = array();

    function &getPropByRef($propName) {
        static $_null = null;

        $_this =& MyGlobals::getInstance();
        if (isset($_this->_properties[$propName])) {
            return $_this->_properties[$propName];
        }
        else {
            return $_null;
        }
    }

    function getPropByVal($propName) {
        $_this =& MyGlobals::getInstance();
        if (isset($_this->_properties[$propName])) {
            return $_this->_properties[$propName];
        }
        else {
            return null;
        }
    }

    function setPropByRef($propName, &$value) {
        $_this =& MyGlobals::getInstance();
        $_this->_properties[$propName] =& $value;
    }

    function setProfByVal($propName, $value) {
        $_this =& MyGlobals::getInstance();
        $_this->_properties[$propName] = $value;
    }

    function __construct() {
        // Perform object initialization here.
        parent::__construct();
    }

    function &getInstance() {
        return parent::__getInstanceImp(’MyGlobals’);
    }
}

We define two types of setters and getters here. One type deals with references and the other type deals with values. This is important because under PHP4, object copy semantics are slightly different from PHP5. Assigning an object to another variable name in PHP4 will result in a deep copy operation. Depending on what the program is trying to do, this can lead to some unexpected results and subtle errors that are very hard to find.

Consequently, the notion of using a Singleton to simulate a namespace extends to the idea of “packages”. A package is a collection of related variables and functions (in other languages, they can also contain other packages as well as classes) that can be accessed using a single namespace.

The functions and variables in a package can be defined as static methods and properties of a class in other languages. In PHP4, while we do have a way of implementing static methods, we have no way of implementing static properties.

This next example takes the notion of simulated namespaces further by defining “static” methods. We call them “static” methods because they make use of “static” properties.

class MyPackage extends SingletonInterface {
    var $staticProperty1;
    var $staticProperty2;

    function staticFunction1() {
        $_this =& MyPackage::getInstance();
        $_this->staticProperty1 = ‘Changed some value’;
    }

    function staticFunction2() {
        $_this =& MyPackage::getInstance();
        $_this->staticProperty2 = ‘Changed another value’;
    }

    function __construct() {
        // Perform object initialization here.
        parent::__construct();

        $this->staticProperty1 = ’some value’;
        $this->staticProperty2 = ‘another value’;
    }

    function &getInstance() {
        return parent::__getInstanceImp(’MyPackage’);
    }
}

MyPackage::staticFunction1();
MyPackage::staticFunction2();
$pkg =& MyPackage::getInstance();
echo “{$pkg->staticProperty1}\n”;
echo “{$pkg->staticProperty2}\n”;

Everything Else Follows…

From these two basic notions, we can come up with many other ways of using the Singleton pattern in our programs. Using Singletons in place of global variables in PHP4 helps to avoid many of the security mishaps that result in the use of global variables. Although there is no silver bullet to creating a completely secure program (much less a secure program in PHP4!), completely eliminating the use of globals is a step in the right direction.

Using Singletons to implement “packages” allows for greater code re-use in PHP4. Although you can always create “packages” by placing all your related functions and globals in one file, you have to contend with naming conflicts as your program grows or as you rely on more and more third-party libraries.

As I have said above, you can extend on the basic notion of the namespace and packages and use the Singleton design pattern to implement the following:

• Centralized configuration object – all the configuration variables and properties that should be accessible during the lifetime of your program can be in one place. This makes it easier to debug your application and it also simplifies the process of performing audits.

• Wrapping superglobals with an object – although not really necessary, wrapping superglobals such as $_SERVER, $_REQUEST, and $_COOKIES into a singleton can be useful when building a library. You can abstract away the details of where these values are coming from and at the same time, you can perform filtering on incoming superglobal values.

• Maintain several database connections – for small to medium-sized applications, a single database connection to a single server will normally suffice. For larger, enterprise-level applications however, you may need to connect to more than one database server.

• Create an “object factory” – a more advanced use case would be to use a Singleton as an object factory. An object factory takes care of instantiating and initializing objects from many different classes and hands them off to the client code. Consequently, objects created by the factory are “registered” into an internal object registry allowing the client code to re-use an instance of an object. The SingletonInterface class is one example of such a factory.

Code re-use, security, and overall ease of maintenance. These are just some of the benefits of using a Singleton in your programs. If you find other uses for this code, or if you have any corrections to make, please post your comments. Please note that I reserve the right to select or reject comments for publishing.

[part-1]: /posts/2006/php4-tricks-the-singleton-pattern-part-i/ “PHP4 Tricks: The Singleton Pattern – Part I”

a

Why would this be a problem? Depending on the PHP setup, either CGI binary or Apache module, the server could end up exhausting file handles under heavy traffic. This issue is even worse on a virtual hosting setup. Virtual hosting allows one to run a website for cheap by sharing a server with several other websites. Because of this shared environments, there is the increased risk of file handle exhaustion leading to failed requests not only for the CakePHP-based website, but for the other hosted websites as well.

CakePHP, by default, loads everything it finds in the app/models directory into memory: even if it’s not used for the duration of the request. The only reason I see why this is done is to ensure that associations work automagically. However, simply loading everything into memory can be wasteful. It wastes memory and processing time because the PHP engine has to load and parse all those files, even if most of it is “dead code” anyway. While this is not a problem in most setups, I have seen hosting services where they do “CPU utilization capping”.

As part of my ongoing project to improve on CakePHP to allow for porting of my old framework, I have decided to implement a modification that allows for lazy-loaded models in CakePHP. The modification has two goals in mind:

1. Allow client code that depends on the mainstream CakePHP to work without problems;
2. Consequently, this allows the programmer to decide what gets to be loaded on each and every request and what gets to be lazy-loaded.

To allow for goal number 1, I had to leave the bootstrap code alone. For number 2, I had to modify the way CakePHP models are instantiated from both the controller and the models themselves. The controller instantiates the appropriate model at runtime. A model may instantiate one or more models from its associations model. But how do you do lazy-loading and still allow for the old model loading behavior?

My solution is to create a new directory under the app/models directory called lazy_load. All models to be lazy_loaded will be placed here. Everything else can stays in app/models.

A new function had to be created to perform the task of lazy loading. The lazyLoadModel() function in the basics.php file takes care of the task. It behaves a fashion similar to loadModel() by loading models from the lazy_loaded directory found in the modelPaths.

Show Me The Code

The changeset for this modification can be found [here][cs-1]. This should apply cleanly to CakePHP version 1.1.8.3544. It should also apply cleanly to version 1.1.10.3825. If you are still using 1.1.8.3544, then you should upgrade to 1.1.10.3825 before applying this patch. Otherwise, you will end up having to manually resolve conflicts. Of course, if you apply this modification, you will end up having to re-apply it with each new version of CakePHP.

Does it work?

I have done a bit of profiling on an example app based on the [Blog tutorial][cake-blog-tut] from the CakePHP Manual as well as tests using [Siege][joedog-siege]. For this test, I created 10 dummy model class files and placed them under the app/models directory as usual and then I ran the profiler from my demo version of Zend IDE. As expected, CakePHP loads everything it can find under the app/models directory and chews up processing time, memory and file handles. The Zend IDE profiler reports that it had to open at least 50 files for the blog app home page.

With Siege, with 100 concurrent requests and with 10000 reps per connection (resulting in 1,000,000 hits total), the server began to cave after the first 4,000 hits and continued to slowdown to at most 40 to 70 seconds on a lot of requests. I was not sure if there were any file handle exhaustion errors since Siege is not able to display the actual page that it requested.

For the second test, I moved all the dummy classes from app/models to app/models/lazy_load I also did the same for the classes that are actually used by the app (post.php and tag.php). First the Zend IDE profiler reports only 40 files are being opened for each request. With Siege, under the same settings as before, the server was able to make it through the ordeal slowing down to 10 to 20 seconds on some requests after about 700,000 hits.

For me, it’s a significant improvement. But you don’t have to take my word for it so go do your own tests and let me know about your results.

Caveats

This is a modification on the mainstream CakePHP code. Which means if anything changes on the mainstream, this modification may also be affected. If you apply the patch to future versions of CakePHP and it results in failed hunks, then you should check what went wrong and take the necessary steps to correct the problem.

Theoretically, the lazy loader should work for plugins too. But I have not tried it yet.

Conclusion

If you like this modification and use it in your production site, please leave a comment here and let me know what you think.

This and other modifications I am making are being made independently from the CakePHP project. As such, you should never report problems you encounter with my modifications to either the CakePHP mailing list or IRC channel. Please report them directly to me.

If you want to send bug fixes or suggestions for improvement, please send email to:

nimrod.abing+blog@gmail.com

Please use the subject line:

PATCH: CakePHP Model Lazy Loader

[cs-1]: http://abing.gotdns.com/cake/diffs/000010-lazy-loaded-models.diff “Changeset for lazy loaded models in CakePHP” [cake-blog-tut]: http://manual.cakephp.org/appendix/blog_tutorial “CakePHP Blog Tutorial” [joedog-siege]: http://www.joedog.org/JoeDog/Siege “JoeDog.org: Siege”

a