I've had a few people contact me indicating interest in Cgiapp, and I've noticed a number of subscribers to the freshmeat project I've setup. In addition, we're using the library extensively at the National Gardening Association in developing our new site (the current site is using a mixture of ASP and Tango, with several newer applications using PHP). I've also been monitoring the CGI::Application mailing list. As a result of all this activity, I've decided I need to develop a roadmap for Cgiapp.

Currently, planned changes include:

• Version 1.x series:

  • Adding a Smarty registration for stripslashes (the Smarty "function" call will be sslashes).
  • param() bugfix: currently, calling param() with no arguments simply gives you a list of parameters registered with the method, but not their values; this will be fixed.
  • error_mode() method. The CGI::Application ML brought up and implemented the idea of an error_mode() method to register an error_mode with the object (similar to run_modes()). While non-essential, it would offer a standard, built-in hook for error handling.
  • $PATH_INFO traversing. Again, on the CGI::App ML, a request was brought up for built-in support for using $PATH_INFO to determine the run mode. Basically, you would pass a parameter indicating which location in the $PATH_INFO string holds the run mode.
  • DocBook tutorials. I feel that too much information is given in the class-level documentation, and that usage tutorials need to be written. Since I'm documenting with PhpDoc and targetting PEAR, moving tutorials into DocBook is a logical step.

• Version 2.x series:

  Yes, a Cgiapp2 is in the future. There are a few changes that are either necessitating (a) PHP5, or (b) API changes. In keeping with PEAR guidelines, I'll rename the module Cgiapp2 so as not to break applications designed for Cgiapp.

  Changes expected include:

  • Inherit from PEAR. This will allow for some built in error handling, among other things. I suspect that this will tie in with the error_mode(), and may also deprecate croak() and carp().

  • Changes to tmpl_path() and load_tmpl(). In the perl version, you would instantiate a template using load_tmpl(), assign your variables to it, and then do your fetch() on it. So, this:

    $this->tmpl_assign('var1', 'val1');
    $body = $this->load_tmpl('template.html');
    

    Becomes this:

    $tmpl = $this->load_tmpl();
    $tmpl->assign('var1', 'val1');
    $body = $tmpl->fetch('template.html');
    

    OR

    $tmpl = $this->load_tmpl('template.html');
    $tmpl->assign('var1', 'val1');
    $body = $tmpl->fetch();
    

    (Both examples assume use of Smarty.) I want to revert to this behaviour for several reasons:

    • Portability with perl. This is one area in which the PHP and perl versions differ greatly; going to the perl way makes porting classes between the two languages simpler.

    • Decoupling. The current set of template methods create an object as a parameter of the application object — which is fine, unless the template object instantiator returns an object of a different kind.

      Cons:

      • Smarty can use the same object to fill multiple templates, and the current methods make use of this. By assigning the template object locally to each method, this could be lost. HOWEVER… an easy work-around would be for load_tmpl() to create the object and store it an a parameter; subsequent calls would return the same object reference. The difficulty then would be if load_tmpl() assumed a template name would be passed. However, even in CGI::App, you decide on a template engine and design for that engine; there is never an assumption that template engines should be swappable.

      • Existing Cgiapp1 applications would need to be rewritten.

  • Plugin Architecture: The CGI::App ML has produced a ::Plugin namespace that utilizes a common plugin architecture. The way it is done in perl is through some magic of namespaces and export routines… both of which are, notably, missing from PHP.

    However, I think I may know a workaround for this, if I use PHP5: the magic __call() overloader method.

    My idea is to have plugin classes register methods that should be accessible by a Cgiapp-based class a special key in the $_GLOBALS array. Then, the __call() method would check the key for registered methods; if one is found matching a method requested, that method is called (using call_user_func()), with the Cgiapp-based object reference as the first reference. Voilá! instant plugins!

    Why do this? A library of 'standard' plugins could then be created, such as:

    • A form validation plugin
    • Alternate template engines as plugins (instead of overriding the tmpl_* methods)
    • An authorization plugin

    Since the 'exported' methods would have access to the Cgiapp object, they could even register objects or parameters with it.

If you have any requests or comments on the roadmap, please feel free to contact me.

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.

The CGI::Application::ValidateRM module utilizes HTML::FillInForm to fill in values in the form if portions did not pass validation. Basically, it utilizes HTML::Parser to go through and find the elements and match them to values. It's used because the assumption is that you've built your form into an HTML::Template, and that way you don't need to put in program logic into the form.

Seems another good candidate for using FillInForm would be to populate a form with values grabbed from a database… I should look into that as well!

I've used HTML::Template a little, mainly in the Secret Santa project I did this past Christmas for my wife's family. One thing I disliked was using the normal syntax: <TMPL_VAR NAME=IMAGE_SRC> — it made looking at it difficult (it wasn't always easy to tell what was an HTML tag, what was plain text, and what was HTML::Template stuff), and it made it impossible to validate my pages before they had data.

Fortunately, there's an alternate syntax: wrap the syntax in HTML comments: <!-- TMPL_VAR NAME=IMAGE_SRC --> does the job. It uses more characters, true, but it gets highlighted different than HTML tags, as well, and that's worth a lot.

And why do I have to say "NAME=" every time? That gets annoying. As it turns out, I can simply say: <!-- TMPL_VAR IMAGE_SRC -->, and that, too will get the job done.

Finally, what about those times when I want to define a template, but have it broken into parts, too? Basically, I want HTML::Template to behave a little like SSI. No worries; there's a TMPL_INCLUDE tag that can do this: <!-- TMPL_INCLUDE NAME="filename.tmpl" -->.

I've been reading a lot of posts lately on the CGI::App mailing list about using CGI::Application::ValidateRM (RM == Run Mode); I finally went and checked it out.

CGI::App::ValRM uses Data::FormValidator in order to do its magic. Interestingly, D::FV is built much like how I've buit our formHandlers library at work — you specify a list of required fields, and a list of fields that need to be validated against criteria, then provide the criteria. It goes exactly how I would have done our libraries had we been working in perl — supplying the constraint as a regexp or anonymous sub in a hashref for the field.

Anyways, it looks like the combination of CGI::App::ValRM with CGI::App could greatly simplify any form validations I need to do on the site, which will in turn make me very happy!

I had some success last night with the My::Portal CGI::Application superclass I'm building — I actually got it working with CGI::Wiki::Simple (after I debugged the latter to fix some delegation issues!). Now that I know the "proof-of-concept" works, I'm ready to start in on some other issues.

The first issue is: how can I specify different directories for different applications to search for templates, while retaining the default directory so that the superclass can build the final page? I could always simply keep all templates in a single directory and simply prefix them, but that seems inelegant, somehow. I'll need to explore how HTML::Template integration works with CGI::App.

Second, and closely related: how do I want it to look, in the end? I could see keeping the design we have — it's clean, simple, and yet somehow functionally elegant. Okay, I'm exaggerating — it's your standard three-column with header and footer. But it goes with the idea of blocks of content. I need to think about that.

I saw a design idea for a WikiWikiWeb today, though, that totally changed my ideas of how a Wiki should look. I hadn't been to Wikipedia for some time, but a Google link to Gaston Julia showed up on Slashdot as it shut down a site in Australia, and so I visited it. I like the new design — it separates out the common links needed into a nice left menu, and puts a subset of that at the top and bottom of the main column as well, using nice borders to visually separate things. I much prefer it to PhpWiki's default style, as well as to anything else I've really seen so far relating to Wiki layout.

I've been struggling with how to use modules at runtime instead of compile time (I even wrote about this once before). I finally figured it out:

my $module = "ROX::Filer";
eval "use $module";
die "couldn't load module : $!n" if ($@);

Now I just need to figure out how to create objects from dynamic module names…!

Update: Creating objects from dynamic names is as easy as dynamically loading the module at run-time:

my $obj = $module->new();

One continual pain for me with perl is when I need to try to find the location of a specific module on my filesystem so that I can examine it myself; I end up first having to find out what my @INC path is, then having to dig through it until I find the module. Fortunately, I'm not the only one; somebody posted a solution to this problem on Perl Monks:

Updated: The original listing presented didn't work! The following one, garnered from a comment to the original PM post, does, and is what I'm now using.

###!/usr/bin/perl -w
use strict;

use File::Spec::Functions qw/catfile/;

my @loaded = grep {
    eval "require $_";
    !$@ ? 1 : ($@ =~ s/(@INC contains: Q@INCE)//, warn ("Failed loading $_: $@"), 0);
} @ARGV;

my @pm = map catfile(split '::') . (/.pmz/ ? '' : '.pm'), @loaded;

print "@INC{@pm}n";
__END__

=pod

=head1 NAME

whichpm - lists real paths of specified modules

=head1 SYNOPSIS

  editor `whichpm Bar`

=head1 DESCRIPTION

Analogous to the UN*X command which.

=cut

Just place it in your $PATH and let 'er rip!