Catalyst versus Mason

[zerohero]

I've been using Mason for a while now and am pretty happy with it, however, I've started running into the typical code separation problems one gets with this paradigm (controller code bound up in view leading to refactoring). Thus I'm starting to evaluate perl MVC frameworks, and Catalyst seems to be the thing that's mentioned most often.

One thing I absolutely hate about MVC frameworks is being "painted into a corner". Especially with things like CRUD. SQL is not that tough, and even though CRUD helps with a large number of simple tables, the core tables in your schema tend to require understanding SQL and your database pretty well. So I'd like to use DBI most of the time, at least until I'm comfortable with the places that a particular ORM is actually helpful. I'm not sure of the ORM that comes with Catalyst, but I've used several, and am not a big fan (not saying there aren't decent ones, but people tend to underestimate the problems in this space).

I'm not interested in saving 20 minutes writing some stupid application (who cares?). I'm more interested in a tool that allows one to write large, manageable web applications in a perl-ish way. Thus, I want a framework that does MVC, is fast, doesn't eliminate freedom in ways that are important (swapping out components, assumption of models that are too simple, etc.). Of course it has to be very perl-ish, have a decent sized community, and execute quickly.

Can someone who has experience with Catalyst provide some guidance as to how well it stacks up in the points above? Also, what's the best way to evaluate Catalyst (e.g. particular web articles which illuminate, etc.)?

[zwon]

With Catalyst you aren't tied to any ORM. The tutorials that come with Catalyst usually propose using DBIx::Class, but actually you can use whatever you want for you model, including DBI.

As for best way to evaluate, I found Catalyst::Manual::Tutorial quite useful.

[perrin]

With the possible exception of Jifty, I think you'll find that Perl MVC frameworks don't paint you into a corner. MasonX::WebApp, CGI::Application, and Catalyst are all totally ignorant of your model and just barely familiar with your view. (MasonX::WebApp expects you to use Mason for templates; the others work with anything, including Mason, for templates.)

All that these tools do is map URLs to method calls and provide some infrastructure for the web-specific parts of the input and output. Otherwise, they stay out of your way.

[Your Mother]

I think you already got a couple of good answers but I want to chime in-

Catalyst rules. You can have any number of models you want. You can have DBI, DBIx::Class, Rose::DB, XML::Feed, 10 external webservices, etc, etc, etc all living together. Most of the examples show DBIC but there are no limits and the framework encourages (though doesn't force) good design choices and separation of the models. In my main personal application I have DBIC as the main model, a plaintext/line-record model for some simple human editable stuff, and I've gone through four different models to represent external feeds as my needs evolved. The only Cat assumption about models is that the model shouldn't need to know about the application (though it can if you really need it) and that the application has nothing to do with the model except for instantiating it (with configuration and arg passing) and using its "API."

Mason v Catalyst can be Catalyst + Mason. Mason is a fine view layer for Catalyst. Catalyst supports arbitrary views too. I've worked on apps that use both Mason and TT2.

Cat has a learning curve but it's fantastic and the only thing it locks you into is its dispatch mechanism which is extremely flexible and hasn't let me down since it got an overhaul about 2 years ago.