Re: Mason + FastCGI

Excerpts from Pedro Melo's message of Wed Sep 30 15:42:51 -0400 2009:
> > I'm sure Dave would say, "why don't you just use Catalyst with  
> > Mason"? But I expect you have a reason, given that you are obviously  
> > aware of Catalyst. :)
> 
> Its a good question, but I did my homework on this one :). Basically  
> Catalyst doesn't add any value to this site:
>
>   * I don't need multiple views per controller, only straight HTML;
>   * all my Model's are alteady abstracted away;

These are strange things to give as reasons to not use Catalyst.  Both View and
Model in Catalyst are pretty thin -- most of the Views are a tiny wrapper
around a templating engine, and most of the Models are a tiny wrapper around
some external class.  Not using Catalyst because you didn't need those misses
the point -- it's like saying "I didn't use Perl because I don't need to
emulate awk's line-splitting behavior."

>   * the URLs are pretty simple, I don't need any chaining stuff.

Hardcoding URLs all over the place is still a bad idea.  $c->uri_for was useful
before Chained became popular, and it continues to be useful independent of
Chained, because it takes things like protocol, hostname, port, and SCRIPT_NAME
into account.

If you'd said:

  * I'm always running my app under a single environment (FastCGI), and I don't
    care about having a standalone dev server
  * I don't need a separate webserver-independent config file for my app
  * My app will never need to change internal structure while maintaining its
    current URL layout
  * My app will never live under any path other than / (or wherever it is
    right now)

I might not believe you on all those points, but you'd at least be saying that
you don't need the core things that Catalyst provides.  (The other feature I
think of as "core Catalyst" is the plugin architecture, which I've left out
because subclassing HTML::Mason::Request is close enough, though that has its
own gotchas too.)

> Besides, the development environment of Mason is much better IMHO. I  
> don't have to restart the app_server.pl everytime I change stuff, only  
> when the models change.

Are you aware of the -r option (restart) to myapp_server.pl in Catalyst?

> And I think that Mason has better performance on production  
> environment: the component preload, and the static_source features are  
> awesome.

Premature optimization, and in any case, is this based on anything more than a
guess?

> But, even if I make a bad decision right now, and the site grows to a  
> point where Cat is actually a better solution, I can still reuse all  
> my Mason components as a Cat view.

Only if you are very disciplined about segregating components that use web
framework features (cookies, etc.) from those which use only templating
features; otherwise you'll need to go back through them all again.

All that said, it's your app, and you should optimize for your time as a
developer.  If you are comfortable with what Mason gives you and aren't
interested in learning (more) Catalyst at this point, go for it.  My intent is
to correct what I think are your mistaken impressions about Catalyst, not to
tell you that using Mason as a standalone framework is always wrong.

hdp.

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf