Since the birth of my daughter, I have not been spending much time coding in PHP, let along writing about it. Recently, however, the professional necessity of developing a new website for the Chiara Quartet that would allow better workflow pushed me back into the coding arena. Basically, we realized that we were maintaining several separate calendars, separate contact lists, and having great difficulty sharing any of these things.
I looked into a couple of possibilties for pre-existing solutions, and decided that no existing framework or CMS fully satisfied my tech needs:
- luddite-friendly. We are musicians, not programmers
- full google calendar API-aware
- full constant contact API-aware
- federated login through OpenID – no more shared easy-to-remember-insecure logins/passwords
- fully separated admin interface from website
- both code and data managed through version control
- easy installation in both a test location and a live location
Although many components satisfy one or more of these requirements, I decided to handle them all through a combination of existing technologies and cobble them together to make a perfect frankenstein monster.
Choosing my stuff
Implementing the google calendar stuff, I decided to use Zend Framework’s code, which worked great. Constant Contact’s API was easily implemented using the docs on their website, and I used PEAR’s OpenID code because it is really easily installable using Pyrus. It turned out to be a bit of a pain because the implementation is not fully maintained, and thus supports neither Google apps OpenID (which is admittedly very complicated and obtuse) or AOL’s OpenID implementation, which uses a redirect. A bit of hackery had that fixed in no time thanks to the OO design of the package.
To enable storing both the code and data in version control, I decided to store all of the data in sqlite3 databases and use PHP’s sqlite3 extension to manage it. This works amazingly well because unlike the old sqlite 2 database (PHP’s sqlite extension), an sqlite3 database will work on any operating system. I chose git to manage the codebase because of its easy cloning and ability to work offline with full revision history and then push to a repository. Using projectlocker.com, I have a private repository accessible via ssh using GPG public keys, so no password problems. In addition, using Pyrus’s excellent and simple facilities for creating a package.xml, I can publish the codebase to the live site directly from the test site on the server, and easily roll back to a previous version in a pinch.
To facilitate the communication between qooxdoo and PHP, I wrote a new, very small and very fast RPC server based on qooxdoo’s internal standard for the things instead of the large and (in my opinion) poorly constructed one that comes by default. I saw a very large performance increase after this, and the online app responds at nearly the speed of a normal desktop app.
The frontend of the website is handled simply by rendering templates in the format defined by PEAR2_Template_Savant, which is to say PHP-based templates that use closures to reduce overhead and to simplify rendering by mapping objects to templates much like Zend Framework‘s Views, but with a much simpler codebase or dependency chain.
Putting it all together
The best thing about all of this was the process of combining these disparate technologies. None of them were designed to work together, but all of them were designed with some basic principles of extensibility that made it possible. By publishing a REST-based standard, Constant Contact made it really easy to utilize their lists to add a contact form to our website. Google’s REST-based standards are second-to-none for anything GData-based. The software I used was also all written with interoperability in mind. When I first began writing PHP code in the days before PEAR even worked on Windows-based machines, when PHP 4.0.6 was new, there was nothing like this. XML-RPC was all the rage, and nobody was doing anything that made it easy to use their code remotely in a completely different language. I love how far we’ve come, and I’m excited to unveil the new site, stay tuned towards the beginning of February!
I’ve attached some screenshots of the administrative backend that uses qooxdoo to show its spartan but fantastic functionality.