Hi Ray --
> I'm looking for some pointers on MVC in this context. Specifically, M
> is easy ... use Perl objects, but how are others implementing the
> Controllers and Views in order to keep them separate?
[...snip...]
> What's the "right" way to do it? (None of this TMTOWTDO stuff now, I
> want the RIGHT way :-) ... and do I have the concepts right?
You want to do it the RIGHT way?
Before diving off into an abstract conversation about "design patters"...
It has been my experience that applying a design pattern such as MVC is not
a panacea. It's more important to devise a system which works than one
which is "academically correct". The most useful thing one can do with
their CS education is often to immediately forget everything they've learned
except the stuff which actually works at a practical level. My point: My
code isn't good because I apply some "pattern" to it. It may be good, and
it may resemble a pattern -- but those two things are largely coincidental.
:-)
That said, MVC has been a corner-stone of how my company develops web apps
in Perl. It has been our architecture for several years. The concepts are
pretty simple, and I think you already have most of the picture. In brief
--
Model: The business logic. Not related to the UI at all.
View: The user interface.
Controller: The glue between the View and the Model.
As you have already identified, the Model is simply a Perl module. The most
important thing to think of when writing a Model module is to make sure you
make it entirely separate from the user interface. It helps me to think of
the methods in the Model as potentially being called from a web application,
a cron script, or an email-based interface. The Model should not contain
anything specific about any of the interfaces through which it might be
accessed.
The View, in a web application, is really the HTML output. Generally, this
will be your templating system. Optimally, the View avoids *ALL*
application logic. At my company we use HTML::Template because it strongly
enforces the separation of View from Controller -- e.g., HTML from code. (I
realize that many of you prefer other HTML templating systems, but I still
contend that HTML::Template is the most effective system for truly
separating HTML from code. And it's damn fast, too.)
The Controller, as I've already described, connects the View to the Model.
Essentially, the Controller takes user input (e.g., HTTP request input, form
data, environment, etc.) and translates it into method calls on the
underlying Model. The Controller then takes output from the Model and
passes it to your View.
We implement our Controllers as CGI::Application modules. CGI::Application
completely encapsulates a single application into an object-oriented Perl
module which runs a particular application. CGI::Application runs perfectly
under mod_perl, and with a little savvy can be made to play nicely with just
about any architecture. Oh yes -- it also runs outside of mod_perl, outside
of Apache, and will even run on Windows should that be one of your
requirements.
As your message indicated, separating the View from Controller is a problem.
In fact, it is actually a problem related specifically to "Server Page"
architectures such as Mason, EmbPerl, Cold Fusion, ASP or JSP. All these
systems are server-page systems (SPS), and all suffer from problems in
separating the View from the Controller.
Ironically, SPS were invented in response to "CGI scripts". CGI scripts
were largely criticized because they, too, combined the View and the
Controller. When you look at it like that it's hard to argue that SPS have
really improved the situation at all.
If you have to work with an SPS such as Mason but you still want to separate
your View from your Controller, you have to work twice as hard. SPSs
encourage the View and Controller to be in the same document. In fact, it's
virtually impossible to entirely separate them. One of the things which
irks me most about SPS code is when I see the re-invention of "old-school,
CGI-style" coding in the middle of a server-page. How do you know when your
SPS is working against you? When you see this in the middle of your
[Mason|EmbPerl|JSP|ASP|Cold Fusion] page:
if (defined($some_form_param)) {
# 50 lines of spaghetti code to run a search
} else {
# 30 lines of spaghetti code to display a form
}
That, my friends, is what happens when an SPS is used in lieu of a real
architecture. Separating your Controller and View is a great cure for this
ailment.
Warmest regards,
-Jesse-
Jesse Erlbaum, CTO
Vanguard Media
http://www.vm.com
212.242.5317 x115
[EMAIL PROTECTED]
