Why Catalyst?

So, let’s start at the top: Why are we using Catalyst? What were we using before? Why did we switch?

Our project began as a simple little “we can knock that out in a couple of weeks” kind of thing. (Yeah, I know, insert foreboding music and laugh track.)

Being no stranger to web site development, and happy to have a project where quick and dirty wasn’t required, we wanted to take some of our real world experience and make a solid, snazzy, sprightly site that ¬†avoided many of the common pitfalls we saw affecting other sites in the same “market space.”

One of our most important decisions was selecting a database. We eventually settled on Firebird: open source, been around forever (since the late 80’s, as InterBase), very stable, real transactions, and a strong, active development community. Unfortunately, after no small amount of work, we ran into a snag that made using Firebird impossible.

We were having some difficulty getting the Perl database connection to do what we needed, and our lead developer was in touch with the plug-in developer as we explored the problem. As time passed, their response went from “Interesting,” to “Hm. It shouldn’t do that…”, to “No, it doesn’t do that, and probably won’t. Sorry.”

There are always things you need to work around when you are building a complex system out of parts but this one was important and just the latest of several gotchas. We were already using DBIx, so our lead dev “jacked up” the project, slid out Firebird, and replaced it with Postgres. It went pretty smoothly, so high-fives all around.

Given that we had to replace the database and any Firebird-specific code, we took a moment to look at the entire project and see if there was anything else that wasn’t quite right, had gone awry, or just wasn’t working.

Our attention immediately fell on the templating system we had devised, based on HTML::Template. I had been using HTML::Template for quite a number of sites and had a pretty good handle on making it do what I wanted. It also let us keep the code and display elements very separate, which would be a requirement if we wanted non-programmers to be able to work on the site. It seemed like a good choice, and we added a layer of code to give us some of the additional features we wanted.

While the system worked pretty well, looking down the road we could see maintaining our home-grown framework could be problematic. We had also been hearing good things about some other open source application frameworks. At first glance none seemed to be an ideal fit but we wanted to give other alternatives some consideration, even if it meant switching to Ruby, Python, or something completely different.

None of the frameworks we considered was an obvious win, but Catalyst seemed to have the least “gotchas” and had some real advantages for us:

  • Perl
  • Did not require mySQL
  • Did not require PHP
  • Choice of template systems (we could stick with HTML::Template, if we wished)
  • DBIx compatible

In general, Catalyst seemed to be the most simpatico with the way our brains were shaped, our understanding of the project’s technical requirements, and seemed to have a development community we felt we could work with.

As we looked at Catalyst more throughly, we saw something similar to what I call the “CPAN coincidence.” When you’re writing something even the slightest bit gnarly, but addresses some general problem, and the thought crosses your mind that surely someone must have already done this–there is about an 85% chance it’s true and you can find it up on CPAN. (What a coincidence!) A number of the things we were grappling with were addressed in Catalyst in ways that made sense and seemed reasonable.

So… we had added an “Object Oriented Relational Database Mapping” subsystem, swapped out the database, were talking about redesigning the data model, adding features we now better understood, and … as a very wise man once said, “Projects are done three times; first to figure out what you’re doing, a second time to figure out how to do it, and a third time to get it right.”

So, we were well on our way to the “second time” before v1.0 was completed. In the long run I think that’s a good thing, but it certainly delayed to our “we can knock that out in a couple of weeks” project.

Given all the other the changes, moving to Catalyst seemed like a good idea at the time.

More as it happens.

Bob Simpson

Leave a Reply

Your email address will not be published. Required fields are marked *