Archive

Over the years I’ve written a number of web applications basically from scratch. I almost always use PEAR and other libraries, but for the most part I’ve always used my own code as the basic framework. Last year I started building a number of modules for Drupal, including some that automate business processes (such as inventory and producing PDF documents for brochures based on live business data). This is convenient because these modules fit nicely into larger intranet type sites for the organizations that use them. But Drupal isn’t really designed to be an application framework. Since it isn’t intended to be that, they apparently feel free to completely redesign key parts of the API between versions, which really makes upgrading expensive.

So more recently I’ve been looking again at a couple of the frameworks that are available for PHP, this time Solar and Zend Framework. I’ve looked at these before, along with Cake. I didn’t care for Cake, and ZF and Solar weren’t ready yet last time I looked.

Solar and ZF are much closer to ready for real use now than they were last time I looked closely at them. Over the weekend I built a few simple prototype level things from both Solar and ZF. The short of it is that I really like Solar. It is very easy, and I found it very intuitive. I shouldn’t be surprised, Paul M Jones has a history of writing good stuff. I had a site running in very short order with Solar.

I think that the main problem with Solar is the size of the community. I need a number of the features that Zend Framework provides, but aren’t available for Solar yet, like SOAP, XMLRPC, RSS, support for MS SQL server connections (I’d rather not need that, but I do), and others. I could write them for Solar, but most of what I need is already available from ZF.

Zend Framework doesn’t have the conceptual consistency and elegance of Solar, and I’m having a hard time piecing together the bits of it that I need. Its sort of like building your own Linux from scratch, maybe something every Linux geek should do at least a couple of times but not something you want to do when all you need is a working computer to get stuff done. When you just need to get work done you want a Ubuntu or OpenSuse to package it for you so you can just get to work.

In the end, ZF is more like PEAR on steroids than it is the framework I want to save me time in piecing something together. Still, I think its the closest to what I need, and it has the momentum and support behind it to have a rosier future. So I guess the best approach would be to build my own blank application from the pieces I will commonly use, with all of the components I commonly will need bundled in already, and archive that as an application template.

A lot has been said about test driven development. While I am a proponent of testing, I am not a fan of test driven development. I could go on at length about it, but actually somebody else has already said it clearly, so here’s a link to what Paul M Jones said about it instead of boring everybody with a retelling here. I’m pretty sure he’s smarter than I am anyway.

I’m working on a mashable page for FH’s intranet, and one of the potential issues is safety if we allow content that isn’t on some “approved list”. That’s exactly the point of Caja (from Google) – “A source-to-source translator for securing Javascript-based web content.”

The Caja page also links to some other pages of groups working on other problems. Most notably:
The Caplet Group (on Yahoo tech groups) : The Caplet Group is discussing the situation of the web browser, in particular the Mashup Problem, and the possibility of using a capability messaging system to allow safe and useful communication between frames, worker pools, and other client technologies.

This leaves you with kind of an ugly array that looks something like this:
[cc lang=”php”]
$_REQUEST[‘search’][0][‘field’] = ‘address:city’;
$_REQUEST[‘search’][0][‘value’] = ‘Phoenix’;
$_REQUEST[‘search’][1][‘field’] = ‘name:full’;
$_REQUEST[‘search’][1][‘value’] = ‘David’;
[/cc]
You generally need to do something with this to make it more usable. A loop like this one transforms it into a more nicely formatted array:

[cc lang=’php’]
foreach($_REQUEST[‘search’] as $key => $value){
$search[$value[‘field’]] = $value[‘value’];
}
[/cc]
I have used this approach quite successfully, and visitors seem to find it easy to work with. If I was doing this now, I would probably use a javascript library to do the clone part. For example, with jQuery, you don’t need the function at all. Just change the onclick on the button to this:
[cc lang=’javascript’]onclick=’$(“#cloneme”).clone().appendTo(“#cloneme”);'[/cc]
In fact, that’s what the working example above actually does.

A long time ago in another job far far away I was responsible for managing system administrators, and for ensuring the eternal availability of all network services. As is the wont of people trying to make sys admin jobs more efficient and tolerable, I wrote a number of automation scripts to collect information from servers and report it centrally. The actual sys admins in the department at the time had their hands full with their day to day work, so I dedicated some of my time building automation tools for them (at the expense of other things on my to do list, I’m sure). Now there are lots of projects you can borrow other people’s hard work to accomplish this, but back then there was less and I did it myself.

During that time I became way too familiar with the /proc directory on Redhat servers. I have since forgotten most of what I knew at the time, but this nice article by Federico Kereki on Linux.com brought quite a bit back for me. Everything you ever wanted to know and more about a host you can get from /proc.

More than the actual results, I remember going through source code figuring out what the information in the /proc files actually meant, and which information could be reliably used to provide which results. Its easy to misuse statistics, as much so on understanding system health as in any other arena.

Anyway, nothing productive to say here, other than the article is worth reading.

I have quite a bit of experience using Drupal, at this point more than with any other CMS platform. In the past I’ve run a variety of others, but by a good margin most of my development on these types of things has been on Drupal. I’ve written several modules for Drupal 4.7 and 5. Of course, I’ve also developed a number of apps and sites that were built from scratch, or on my own code base, or on miscellaneous other products that someone else implemented and then I got to fix, but those are a different issue altogether.

I have been facing the release of Drupal 6 with some trepidation. I have a number of deployed Drupal 5 modules out there (I think all of the 4.7 sites that use my modules have been updated by now), and the job of updating the modules is daunting. There needs to be a pretty compelling reason, I think, to update them, considering the amount of work that is going to be required.

I should probably say that none of these modules are released publicly. They were all to solve specific business needs, mostly of my primary employer (Food for the Hungry). Updating the modules would mean updating the private sites that use them to Drupal 6 as well.

Now that Drupal 6 has been released, I don’t see any compelling reason to bother. Yes, Drupal 6 has a number of very good improvements. Its a good product, and they are continuing to take it in a very promising direction. But the improvements for an established site don’t rise to any huge reason to spend significant time updating these sites. And it would take quite a bit of effort, since the changes are considerable.

I also considered moving this blog back to Drupal, since that is the software on which I base so much of my ongoing work. There is little chance that my development work will stop emphasizing Drupal. However, Drupal does not do anything like the nice job on basic blogs that WordPress does. I guess that’s partly a difference between a more generalized content system (and for me framework for business process automation oriented modules) and a more specialized blogging package like WordPress. I’m fairly confident I would not try to do the things with WordPress that I can do with Drupal. On the other hand, for a basic blog, WordPress is much nicer.