The new weierophinney.net/matthew/ site is now up and running!

The site has been many months in planning, and about a month or so in actual coding. I have written the site in, instead of flatfiles, PHP, so as to:

• Allow easier updating (it includes its own content management system)
• Include a blog for my web development and IT interests
• Allow site searching (everything is an article or download)

I've written it using a strict MVC model, which means that I have libraries for accessing and manipulating the database; all displays are template driven (meaning I can create them with plain-old HTML); and I can create customizable applications out of various controller libraries. I've called this concoction Dragonfly.

There will be more developments coming — sitewide search comes to mind, as well as RSS feeds for the blog and downloads.

Stay Tuned!

On PhpPatterns, I recently read an article on Template Engines in PHP. It got my ire up, as it said (my interpretation):

• "template engines are a bad idea"
• "templating using PHP natively can be a good idea"
• "template engines… are not worth the text their written in"

Okay, so that's actually direct quotes from the article. I took issue with it, immediately — I use Smarty for everything I do, and the decision to do so was not done lightly. I have in fact been advocating the use of template engines in one language or another for several years with the various positions in which I've been employed; I think they are an essential tool for projects larger than a few pages. Why?

• Mixing of languages causes inefficiency. When I'm programming, it's incredibly inefficient to be writing in up to four different languages: PHP or Perl, X/HTML, CSS, and Javascript. Switching between them while in the same file is cumbersome and confusing, and trying to find HTML entities buried within quoting can be a nightmare, even when done in heredocs. Separating the languages into different files seems not only natural, but essential.
• Views contain their own logic. In an MVC pattern, the final web page View may be dependent on data passed to it via the Controller; however, this doesn't mean that I want the full functionality of a language like PHP or Perl to do that. I should only be doing simple logic or looping constructs — and a full scripting language is overkill. (I do recognize, however, that template engines such as Smarty are written using PHP, so the language is being invoked regardless. What I speak of here is the language used to compose the template.)
• Abstraction and Security. The fewer internals that are divulged on the template page, the better. For security purposes, I may not want clients able to know how data got to the page, only what data is available to them. In addition, if this data is abstracted enough, any number of backends could be connected to the page to produce output.

So, reading the aforementioned article really got my hackles up. However, it got me thinking, as well. One issue raised is that PHP can be used as your templating language. While I can understand why this might be desirable — everything from load issues to flexibility — I also feel that this doesn't give enough abstraction.

Using PHP seems to me to be inefficient on two fundamental levels, based on my understanding of The Pragmatic Programmer:

• Domain Langauge. The Pragmatic Programmer suggests that subsets of a language should be used, or wholly new mini-languages developed, that speak to the domain at hand. As an example, you might want to use a sharp tool to open a can; an axe would be overkill, but a knife might work nicely. Using PHP to describe a template is like using an axe to open a can; it'll do the job, but it may also make a mess of it all, simply because it's too much sharp edge for the job.
• Metadata. Metadata is data about data; to my thinking, templates describe the data they are communicating; the compiled template actually contains the data. In this regard, again, putting PHP into the script is overkill as doing so gives more than just some hints as to what the data is.

The author of the article also makes a case for teaching web designers PHP — that the language is sufficiently easy to pick up that they typically will be able to learn it as easily, if not more easily, than a template language. I agree to a degree… But my experience has shown that web designers typically struggle with HTML, let alone PHP. (Note: my experience in this regard is not huge, and I'm sure that this is an exaggeration.) I find that it's typically easiest for me to give an example template, explain what the funny, non-HTML stuff can do, and let them go from there. Using this approach, they do not need to learn anything new — they simply work with placeholders.

Still, I think the author raises some fine points. I wish he'd bothered to do more research into why people choose template engines and the benefits that arise from using them before simply outright slamming them. Of course, the article is also a bit dated; it was written over two years ago, and much has changed in the world of PHP and many of its template engines. I'm curious as to whether they would feel the same way today.

Me? My mind is made up — the benefits, in my circumstances, far outweigh any costs associated. I'll be using template engines, and Smarty in particular, for years to come.

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