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
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
