Interestingly enough (at least to me), it was a year ago Wednesday that I was sitting up, listening to the rain pound on a Pacific Northwestern roof, reviewing the disorganized state of Perl web development. Then, unlike now, grand visions of vast OO architectures, transparent caches, and a re-vamped Protest.net danced in my head. Tonight I’m just hacking a personal project because I can’t sleep.

I made my peace with Class::DBI tonight, or at least until I find something else about it that boggles, confuses, and frustrates me. It takes a real leap of faith, and a cast iron “La la la, I’m pretending its not there” outlook to switch from writing carefully hand crafted SQL, with delicate multi-table (inner outer left cross hectic) joins, to letting CDBI do its relatively naive (by design) thing. I recommend turning on the MySQL query log just to get a sense of how it CDBI works, useful while you’re still trying to understand the syntax, and to do what limited tuning is allowed through the interface. (still a novice admittedly) And then turn it off, and try to forget what you saw, helps if you’re the type to repress scarring memories.

So I’ve got Class::DBI, and Template Toolkit is a shoe in, I feel like CGI::FormBuilder is the last piece of the puzzle, to making really lazy (in the best possible sense of the word) Perl web applications. But…. ### Lets Talk Features

CGI::FormBuilder has a great set of features, a little over the top at times, but generally real solid, and easy to use, and amazing documentation. However, its object orientation is a very thin veneer over a procedural heart, and therein lies the problem. My ideal system is at once not that far off from CFB, and yet worlds away. A good Form class should

  • Handle parsing of CGI variables, naturally
  • Aid in rendering your form
  • Have at least hooks for validation

All of which CFB does, in spades. Also

  • Not try to do all the rendering for you. (see my PHP, A Few Tips)
  • Allow subclassing – I want an object for each form in my application
  • Allow subclasses to define complex input types like an image upload field, or a date field (3 constrained pull downs, or maybe a text field+dhtml widget). This is where CGI::FormBuilder seems to me to lose biggest not going the OO route.
  • Allow form defaults to be set from objects (for example Class::Accessor aka Class::DBI objects) not just hashrefs

More on Template Integration

CGI::FormBuilder has native support for HTML::Template, and Template::Toolkit which is great. What that means in the context of CFB is it is capable of accepting a template specification as part of its render method. That leads to inside out code. (or so it seems to me) Ideally I would like to be able to pass a form object to a template and use it like so. ```

Name: [% form.name.html %] Email: [% form.email.html %] ... ``` Rather then having to pass my template to the form object, and use it to draw every aspect of the form. I did find this [clever, but evil hack](http://perlmonks.thepen.com/270363.html) to move in this direction, but the idea is to be lazy in a way you can be proud of, and faking a template to capture the rendered variables is just a little too much. ### More on Complex Input Types I’ve got events, calendars, and dates on my mind again, what a surprise. So the “Image Upload” input type was just thrown in there to make it seem like I had thought about this a little more. I want to be able to pass a form element object a [DateTime](http://search.cpan.org/dist/DateTime/) object, and get 3 properly configured pull down menus. Similarly I want to be able to ask CFB for the value of my date field, and get back a DT object, not ${name}*day, ${name}*month, ${name}\_year. Of course you would probably have to hold on to the values the user submitted in order to re-display the form on an error condition, but tuck it away somewhere I don’t have to see it. Seems like Class::DBI’s inflate/deflate API would be a good model for this. This is where you chime in and tell me you’ve heard my pleas and written the perfect solution, or that its been sitting on CPAN for the last 8 years, its called cgi-lib.pl, and how have I missed it.