[Catalyst] Re: CGI.pm and Catalyst?

[Darren Duncan]

At 11:39 AM +0100 3/7/08, Aristotle Pagaltzis wrote:
>It's a really really REALLY bad idea to mix your display logic
>into your controllers, much less your model.
>
>Most people therefore say that you should use a template system
>with a minilanguage. But the reason that doing this is good is
>that it forces you to write your display logic in a separate file
>without easy access to the rest of the code.
>
>In other words, it forces you to properly separate concerns: the
>controllers only translate HTTP into model and view calls, and
>only the model has business logic, and the view does nothing else
>than translate the stash into output.
>
>But the language in which your display logic is written doesn't
>much matter. (In fact, the minilanguages are usually terrible,
>like writing shell and awk scripts when you could be writing
>Perl.) It's not an issue to write Perl to generate your output,
>as long as you keep that Perl code in separate modules whose
>*only* job is to render the stash.

Speaking for myself (who is now on the cusp of starting to use 
Catalyst for the first time, and is now reading "the book" to learn 
it), I have for the last several years been writing my new web 
applications with very few external dependencies, with said 
applications using DBI and SQL directly, and producing their own 
HTML, both without help from a generic templating wrapper or generic 
DBI wrapper.

That said, the applications were well structured and highly resembled 
the MVP practices that Catalyst is built on.  Practically all of the 
code was in modules, except for a thin wrapper which invoked the 
otherwise controller main in an eval block so to trap and report 
otherwise unhandled compile or runtime exceptions.  Its controller 
logic and HTML-making view code were in separate per-application 
modules; the controller examined user input, determined what page to 
display (using the path_info mainly) and gathered data to use; the 
view was invoked almost just before the controller exited, and 
rendered the page the controller told it to do.  Utility modules 
wrapped DBI, and wrapped the web client input/output (including 301s 
etc), uri generation, and managed sessions (the last 3 with CGI.pm 
and CGI::Session and File::VirtualPath) and the stash.  For 
configuration, the controller starts by do-ing a Perl file that 
simply contained an anonymous Perl hash declaration, so Perl itself 
is the config file parser.  Many more similarities that I won't 
detail here.

Suffice it to say that as I've been reading "the book", I very much 
understand the reasoning of how Catalyst-using applications, and the 
framework, are structured, as its essentially the same as what I was 
doing, but that with Catalyst a greater part of the codebase will be 
generified and higher quality.  The first main benefit I anticipate 
getting from switching to Catalyst is improved server portability, 
and in particular the ability to develop and test an app without 
running it on the actual Apache server.

Getting back to the topic at hand, I think it works very well for a 
view to simply be written in Perl, and in many cases it seemed to 
work better than the templating approach I had seen in PHP 
applications.

That said, as per the examples in "the book", I intend to try using a 
non-Perl template approach (TT or something) at the same time as 
adopting Catalyst, and see how well that works out.

At the same time, I'll also move to using an alternate database 
access method than direct DBI+SQL, which would be my first use of 
Muldis DB.  Note that many of my database queries are relatively 
complicated and would have required writing a lot of SQL anyway were 
I to use any other DBI wrappers / ORMs, afaik.

-- Darren Duncan