Suggest some good MVC framework in perl [closed]

Question

Can you suggest some good MVC framework for perl -- one I am aware of is catalyst

The need is to be able to expose services on the perl infrastructure which can be called by Java/.Net applications seamlessly.

Answer 1

I'll tell you right now that Catalyst has by far the best reputation amongst Perl developers in terms of a rapid application development MVC framework.

In terms of "pure" MVC I'm not sure there are even that many "mature" or at least production-ready alternatives.

If Catalyst doesn't seem right to you, then you could build upon the lightweight framework CGI::Application to suit your needs or take a look at some of the lesser known MVC frameworks like PageKit and Maypole.

Answer 2

Another options is Gantry when used in conjunction with the BigTop module it can reduce the time it takes to build simple CRUD sites.

Answer 3

For your problem I would take a look into Jifty::Plugin::REST which allows access to models and actions using various formats.

Let me just say that Jifty doesn't have terrible documentation. However, most of included documentation is API documentation, but there is very low-noise mailing list which has useful tips and links to applications.

Wiki at http://jifty.org/ is another resource which has useful bits.

If your goal is to make video store (my favorite benchmark for 4GLs and CRUD frameworks) in afternoon, it's really worth a look!

Answer 4

If you are already aware of Catalyst, then I recommend focusing on it. It is mature, well-documented, and has a very large user-base, community, and collection of plug-ins.

Answer 5

Seconding comments made by others: Catalyst (which more or less forked from Maypole) is by far and away the most complete and robust of them. There is a book by Jonathan Rockway that will certainly help you come to grips with it.

In addition to the 'Chained' dispatch type, the :Regex (and :LocalRegex) dispatch methods provide enormous flexibility. The latest app we've built here supports a lot of disparate-looking URLs through just a handful of subs using :LocalRegex.

I also particularly like the fact that you are not limited to a particular templating language or database. The mailing list (and the book) both have a preference for Template::Toolkit (as do I), and DBIx::Class (we continue to use Class::DBI), but you can use pretty much anything you like. Catalyst is marvelously agnostic that way.

Don't be put off by the fact Catalyst seems to require half of CPAN as dependencies. Once you get it up and running, it is a well-oiled machine. It has reached a level of maturity now that once you come to grips with it, you find it 'fades into the background'. You spend your time solving business needs, not fighting with the tools you use.

It does what it says on the tin. Catalyst++

Answer 6

Another alternative besides the ones already mentioned is Continuity; however, it is (as the name is meant to imply) continuation-based rather than MVC in the typical sense. Still, it’s worth mentioning because it is one of the better Perl web frameworks.

That said, I like Catalyst much better than any of the alternatives. And it’s still getting better all the time! The downside of that is that current preferred coding approaches continue to evolve at a fairly hurried clip – but for the last couple of versions, there has been strong emphasis on API compatibility, so the burden is now mostly mental rather than administrative. The upcoming port of the internals to Moose in particular is poised to provide some excellent benefits.

But the biggest argument in favour of Catalyst, IMO, is the Chained dispatch type. I have seen nothing like it in all of web-framework-dom, and it is a most excellent tool to keep your code as DRY as possible. This couples well with another great thing that Catalyst provides, namely uri_for – a method which takes a controller and a bunch of arguments and then constructs a URI that would dispatch to that place, which it returns. Together, these facilities mean that you can structure your URI space any way you deem right, yet at the same time can structure your controllers to avoid duplication of logic, and keep templates independent of the URI structure.

It’s just brilliant.