web2project: Goodbye PHP4

Design Patterns by The Gang of FourWell, PHP4 has been officially dead for over six months.  While there are hosting companies – and even Linux distros – that package PHP4, for all intents and purposes, it's dead and won't see any further updates or fixes.  And this is a good thing.

Anyway, during our recent flurry of development on web2project, we noticed that we broke PHP4 compatibility.  While we – mostly me – initially didn't do it on purpose, it made quite a bit of sense for a number of reasons:

First, we can't lag behind the community.  One of my major complaints with many Open Source projects is the lack of updates they receive.  Recently, I had to track down and attempt to use a project which hadn't seen an update in over three years.  While it makes sense for a project to die if it's being replaced by something better… lagging just because no one has updated it is a failure of the project.

Second, we have real better Object Orientation.  I'd love to go into this one, but I know my friend and colleague Matthew Turland is covering this is great detail tomorrow on the Blue Parabola blog, so I won't steal his thunder.

Next, we have real XML handling.  In order for the system to be used and extended by various "enterprisey" organizations, they need to interact with the system in ways they understand.  Let's face it, this is XML with various CSV's (ew) being a second choice and JSON being a distant third.

By pushing the system to be PHP5 only, we can count on (and use!) things like SimpleXML to create and parse XML.  Of course, the built-in SOAP handling becomes an option too… but I try to block that out of my mind. 😉

Finally, we can use our data structures and where we allow access to set an agenda.  By using simple aspects like "public", "private", and "protected", we can help guide and direct those who wish to extend the system towards a coherent model in how the system works.

If you want to see a poor example of module handling, osCommerce is king.  It requires numerous copy/paste operations in a variety of files, a database script to be executed, and the sacrifice of a virgin to a volcano in order for modules to function properly.  Drupal and Joomla tend to handle modules completely differently (aka sanely).  They provide a clean way of extending the system through existing API's and hooks.  Towards that goal, we've used the Drupal hook system as a model of what works.  While it's not perfect, it's significantly better than what we've had before.

Tomorrow, I'll go into our hooks system, some areas for improvement, and describe how you can use it in your own extensions…