[sf-perl] All these Perl web frameworks

[Bryan Beeley]

On 08/01/2012 01:39 PM, Joseph Brenner wrote:
>> Catalyst- http://www.catalystframework.org/ - grandaddy of the big
>> active frameworks? Lots of modules / flexibility?
> Yes, I think that's about the size of it.

I have used Catalyst extensively, and would definitely recommend it.  It 
is a huge memory hog though.  I would also recommend you take advantage 
of copy-on-write as much as possible (load as much as possible into 
memory before forking child Catalyst processes).

>> Mojolicious- http://mojolicio.us/
> A lot of us seem to agree that Mojolicious is a scary project.
> They're main feature is they've reduced external dependencies, but
> that means they've re-written a lot of stuff from scratch themselves.

I don't know much about Mojolicious.  I was on their mailing list for a 
while though, and it didn't seem like things were moving very fast.

>> Dancer- http://perldancer.org/
> I've got a vaguely positive vibe about dancer, though at this point I
> can't remember why... I gather Catalyst is more configurable.

I have heard that Dancer is nice and much lighter weight than Catalyst.  
Probably better for quick, simple projects where Catalyst would be 
overkill.  I haven't had any direct experience with it though.

>> Poet- http://search.cpan.org/~jswartz/Poet-0.09/lib/Poet/Manual/Intro.pod
> I would say that Jonathan has a good point that while the various
> MVC-style frameworks talk-up "separation of concerns" really the
> pieces end up being pretty tightly-coupled, and you have to keep
> making parallel changes everywhere.

As with a lot of things, I think there are a lot of design decisions 
that can be made to keep things more separate.  What worked for the last 
big project I was on was to move all the code dealing with the model 
into a Form object (we use HTML::FormHandler).  This makes the 
controllers very simple, and allows you to test your forms separately 
from your Controllers.  Assuming you will be using DBIx::Class, you can 
help to keep things less tightly-coupled by putting any complicated 
searches into custom ResultSet methods. Doing so makes it more likely 
that you will be able to make model changes without having to touch code 
outside of the model.

> Also, using Mason by default appeals to me more than TT, it feels much
> more perlish.

I feel like using TT is great because its is too simple to do anything 
too complicated well but flexible enough to allow you to make most pages 
work when only passing in a form object -- encouraging more separation 
of concerns.

Bryan