We've been working with Catalyst now for about a week.

I thought I'd share some observations, issues, theory, and praise.

Perhaps others starting out with Catalyst will find something here helpful.


  • Catalyst smartly leverages well-established perl technology. If you're not familiar with Class::DBI and (TT|Mason), it might be worth your while getting some of those concepts and idioms straight before diving into Catalyst (hereafter, "Cat"). We were fortunate to come to Cat from reasonably strong CDBI and Mason backgrounds.
  • The docs are sparse but good.
  • The Cat IRC channel is really solid. Thanks, sri.
  • Cat uses some automagicification, but not too much. (Say goodbye to  use statements!) Didn't bother any of our folks. Felt right.
  • Plugins are great. I was able to add in authentication to an intranet in about 10 mins. Persistent sessions in about 10 minutes. Amazing stuff.
  • The helper scripts are interesting. As we have our own "generate CDBI model from current dev DB schema" scripts, we didn't use them that much.
  • It is very easy to use your own Model.
  • While it is neat to use the Scaffolding framework to build a CRUD screen in 90 secs, they're ugly and simple, and we found ourselves hand-rolling a form displayer met our needs (eg present enum fields as pulldowns, present FK fields as pulldowns, present booleans as yes/no radio buttons, formatting, nice labels, help tooltips, etc.)


  • It'd be great to have Cat movies in English, with voice-over.
  • The biggest limitation to the docs is that they don't explain the model-view-controller paradigm yet. We asked lots of questions on the Cat IRC channel before getting that straightened out in our minds.
  • The other limitation of the docs is that we don't think they're up-to-date with the newest release... some features aren't doc'd yet.
  • It'd be great to add "M-V-C Theory 101" section to the docs.
  • When we wrapped our CDBI class in a Cat model, something somewhere was holding a reference to the CDBI object, and the app wasn't seeing commits. We've seen this before in other contexts. The problem went away when we started using our own CDBI model directly from our Cat apps, rather than wrapping the CDBI objects in a Cat package wrapper. (Not sure why we started with a wrapper, but we did.)
  • Sometimes we had trouble using $c->forward to reach a method in the same package... probably we specified the path wrong. In these cases we gave up and called the method as a method ($self->foo($c) rather than $c->forward('/we/had/the/path/wrong/foo')).
  • The Cat gang embrace TIMTOWTDI to an extreme. TIMTOWTDI is great, but for newcomers, some recommended practices / examples would be helpful, esp. on the topic of structuring an app (directories and actions) and M-V-C design strategy.


I didn't understand M-V-C. Here's my limited understanding so far. You may have different preferences or ideas. TIMTOWTDI, of course. But please share your thoughts on this -- I'm still learning this theory!
  • The model handles the database stuff. You want to fetch or make a persistent object? Ask the model. For us, model = CDBI. Since we already had a heavy solid feature-rich auto-generated CDBI framework in place (field checking, autodiscovery of has_a and has_many relationships, integrity constraints, etc), we've opted to use our CDBI classes as our Cat models with no additional wrapping. (See comment above about our issues with wrapping and commits, too.) So, the model is a way to hide the DB and the sql.
  • The View handles presentation stuff. The view makes it look nice, period. No heavy lifting or business logic in the view. Now, we're not adverse to the View using the Model to get more data for display. For example, say we pass an employeeid to the View via the cache, rather than an employee object; we're cool with the View fetching the Employee from the model. We'd not be cool with a View going off and changing the Employee in any way ("Hey, here's a raise!"). We also place trivial biz logic in the view, such as "only display active employees in the employee pulldown list" -- the View is empowered (understands the biz logic) to check the 'active' field in each Employee logic.
  • The Controller does the real work. Controller handles biz logic ("You can't give a raise to a fired employee"). The Controller handles the flow through the app. ("After user hits submit, check the form is OK, and if so, put into the DB and redirect to the next step, else place them back on the form with the bad fields highlighted in red.") At its essence, the controller is the app.
There were discussions on the Cat IRC channel about "thin controller, fat model" vs. "fat controller, thin model" -- we opted for the later.


Catalyst does indeed rock mightly.

High praise to the Catalyst team for a great piece of technology, which smartly employs MVC and wisely leverages CPAN.

If you're thinking about using a framework or have Ruby-On-Rails jealously, give Cat a few days to see if you like. Our shop did that; we do like it; we have small Cat intranet apps already in production and deployed after about a week.

Comments welcome, esp. on the theory of what-work-goes-where in an MVC framework.