After working on some OO classes yesterday for an application backend I'm developing for work, I decided I needed to create a BREAD class to make this simpler. You know, Browse-Read-Edit-Add-Delete.

At first, I figured I'd build off of what I'd done yesterday. But then I got to thinking (ah, thinking, my curse). I ran into the BREAD concept originally when investigating CGI::Application; a number of individuals had developed CGI::Apps that provided this functionality. I'd discarded them usually because they provided more functionality than I needed or because they introduced more complexity than I was willing to tackle right then.

But once my thoughts had gone to BREAD and CGI::App, I started thinking how nice it would be to have CGI::Application for PHP. And then I thought, why not? What prevents me from porting it? I have the source…

So, today I stayed home with Maeve, who, on the tail end of an illness, evidently ran herself down when at daycare yesterday, and stayed home sleeping most of the day. So, while she was resting, I sat down with a printout of the non-POD code of CGI::App and hammered out what I needed to do. Then, when she fell asleep for a nap, I typed it all out and started testing. And, I'm proud to say, it works. For an example, visit my development site to see a very simple, templated application in action.

I was lamenting at work the other day that now that I've discovered OO and templating with PHP, the only major feature missing for me is a way to easily document my programs. I'm a big fan of perl's POD, and use it fairly extensively, even for simple scripts — it's a way to provide a quick manual without needing to worry too much about how to format it.

So, it hit me on the way home Friday night: what prevents me from using POD in multiline comments of PHP scripts? I thought I'd give it a try when I got home.

First I googled for 'POD for PHP', and found a link to perlmongers where somebody recounted seeing that exact thing done, and how nicely it worked.

Then I tried it… and it indeed worked. So, basically, I've got all the tools I love from perl in PHP, one of which is borrowed directly from the language!

I've been researching and coding for a couple months now with the decision that I'd rewrite the family website/portal using mod_perl with CGI::Application. I still like the idea, but a couple things recently have made me rethink it.

For starters, the perl DBI is a bit of a pain to program. At work, I've become very accustomed to using PEAR's DB library, and while it's in many ways derived from perl's DBI, it's much simpler to use.

Then there's the whole HTML::Template debacle. There's several ways in which to write the templates, but they don't all work in all situations, and, it seems they're a bit limited. We've started using PHP's Smarty at work, and it's much more intuitive, a wee bit more consistent, and almost infinitely more extendable. I could go the Template::Toolkit route for perl, but that's almost like learning another whole language.

Then, there's the way objects work in perl versus PHP. I've discovered that PHP objects are very easy and very extendable. I wouldn't have found them half as easy, however, if I hadn't already been doing object oriented programming in perl. One major difference, however, is how easy it is to create new attributes on the fly, and the syntax is much easier and cleaner.

Add to that the fact that if you want to dynamically require modules in perl, you have to go through some significant, often unsurmountable, hoops. So you can't easily have dynamic objects of dynamically defined classes. In PHP, though, you can require_once or include_once at any time without even thinking.

The final straw, however, was when I did my first OO application in PHP this past week. I hammered it out in a matter of an hour or so. Then I rewrote it to incorporate Smarty in around an hour. And it all worked easily. Then I wrote a form-handling libary in just over two hours that worked immediately — and made it possible for me to write a several screen application in a matter of an hour, complete with form, form validation, and database calls. Doing the same with CGI::Application took me hours, if not days.

So, my idea is this: port CGI::Application to PHP. I love the concept of CGI::App — it's exactly how I want to program, and I think it's solid. However, by porting it to PHP, I automatically have session and cookie support, and database support is only a few lines of code away when I use PEAR; I'll add Smarty as the template toolkit of choice, but make it easy to override the template methods to utilize . I get a nice MVC-style application template, but one that makes developing quickie applications truly a snap.

This falls under the "right-tool-for-the-job" category; perl, while a wonderful language, and with a large tradition as a CGI language, was not developed for the web as PHP was. PHP just makes more sense in this instance. And I won't be abandoning perl by any stretch; I still use it daily at work and at home for solving any number of tasks from automated backups to checking server availability to keeping my ethernet connection alive. But I have real strengths as a PHP developer, and it would be a shame not to use those strengths with our home website.

We're starting to use OO in our PHP at work. I discovered when I started using it why I'd been having problems wrapping my head around some of the applications I've been programming lately: I've become accustomed in Perl to using an OO framework. Suddenly, programming in PHP was much easier.

There's a few things that are different, however. It appears that you cannot pass objects in object attributes, and then reference them like thus:

$object->db>query($sql)

PHP doesn't like that kind of syntax (at least not in versions 4.x). Instead, you have to pass a reference to the object in the attribute, then set a temporary variable to that reference whenever you wish to use it:

$object->db =& $db;
...
$db = $object->db;
$res = $db->query($sql);

What if you want to inherit from another class and extend one of the methods? In other words, you want to use the method from the parent class, but you want to do some additional items with it? Simple: use parent:

function method1()
{
    /* do some pre-processing */

    parent::method1(); // Do the parent's version of the method

    /* do some more stuff here */
}

Update:

Actually, you can reference objects when they are attributes of another object; you just have to define the references in the correct order:

$db =& DB::connect('dsn');
$this->db =& $db;
...
$res = $this->db->query($sql);

I've tested the above syntax with both PEAR's DB and with Smarty, and it works without issue.

I was just reading an article about the Dean campaign's IT infrastructure, and there's an interesting quote from their IT manager, Harish Rao:

"I believe in three principles", he said. "First I always make sure I hire people I can trust 100%. Second, I always try to hire people who are smarter than I am. Third, I give them the independence to do as they see fit as long as they communicate about it to their other team members. We've had a lot of growing pains, a lot of issues; but we've been able to deal with them because we have a high level of trust, skill and communication."

I know for myself that when I (1) don't feel trusted, and/or (2) am not given independence to do what I see as necessary to do my job, I don't communicate with my superiors about my actions, and I also get lazy about my job because I don't feel my work is valued.

Fortunately, I feel that in my current work situation, my employers followed the same principles as Rao, and I've felt more productive and appreciated than I've felt in any previous job.

I've been thinking about trying to standardize the PHP code we do at work. Rob and I follow similar styles, but there are some definite differences. It would make delving into eachother's code much easier if we both followed some basic, agreed upon, guidelines.

One thing I've been thinking about is function declarations. I find that I'm often retooling a function to make it more general, and in doing so either need to decrease or increase the number of arguments to it. This, of course, breaks compatability.

So I propose that we have all functions take two arguments: $data and $db. $data is a hash which can then be extract'd via PHP. To change the number of arguments, you can simply set defaults for arguments or return meaningful errors for missing arguments.

Another thought going through my mind deals with the fact that we reuse many of our applications across our various sites, and also export some of them. I think we should try and code the applications as functional libraries or classes, and then place them somewhere in PHP's include path. We can then have a "demo" area that shows how to use the libraries/classes (i.e., example scripts), and to utilize a given application, we need simply include it like: include 'apps/eventCalendar/calendar.inc';. This gives us maximum portability, and also forces us to code concisely and document vigorously.

I was also reading on php.general tonight, and noticed some questions about PHP standards. Several people contend that PEAR is becoming the de facto standard, as it's the de facto extension library. In addition, because it is becoming a standard, there's also a standard for documenting projects, and this is phpdocumenter. The relevant links are:

• PEAR Coding Standards
• phpDocumentor