Jesse is a friend of mine, and I think you're misinterpreting what he says there. He's just pointing out that an MVC approach avoids scattering your controller code through a bunch of in-line code in multiple HTML files. It applies to all MVC frameworks. | [reply] |
Here are the quotes I've misinterpreted if that's the case. I think they are quite readily interpreted the way I have read them.
The most savvy programmers quickly realized that run-modes are a specific thing that must be directly managed, and the most succinct way to determine the run-mode is to explicitly set it. Some systems, such as ASP, HTML::Mason, Cold Fusion and JSP attempt to manage these run-modes by having one physical document for each run-mode. This has the effect of spreading the code for a single application over at least as many files as there are run-modes! Taking the run-modes out of context by breaking them into separate files solves the state management problem at the cost of creating all sorts of new problems, not the least of which is the management of code assets. These run-modes are, after all, all part of the same application.
Second, CGI::Application maps each run-mode to a specific Perl subroutine. Each subroutine, referred to as a "Run-Mode Method", implements the behavior of a single run-mode. All of your code, including all your run-mode methods and the mapping table between run-modes and subroutines, is stored in a single file. This file is a Perl module, referred to as your "Application Module".
In traditional CGI programming, we might have a file, myapp.cgi, which is requested by a Web browser. The Web server (based on its configuration) will treat this file as a program, and return the output of its execution (as opposed to its content). In traditional CGI, this file would contain all your application code, and it would be quite lengthy. Using CGI::Application, we have put all our code in our Application Module, instead. This means that the actual file executed by the Web server can be completely empty of application-specific code! As a matter of fact, for our prototypical "WidgetView" application, what follows is the entirety of widgetview.cgi:
#!/usr/bin/perl -w
use WidgetView;
my $app = WidgetView->new();
$app->run();
It certainly seems from reading the above that Jesse was, in 2001 at least, advocating putting the entire codebase, or nearly so, for an application in a single file. He was also implying that certain other frameworks were not only discouraging but incapable of combining multiple of these "run modes" into a single file. If as one of Jesse's friends you understand those quotes differently, then there's some communication gap between your circle of friends and mine.
I'm sure Jesse's a very nice person and makes good, solid applications. I just don't agree with some of the statements I thought he was making in that article. What I thought he meant when he wrote that in 2001 I wouldn't expect him to necessarily think in 2009 anyway. People can and have been known to change their minds on such issues. Where the writing could be pretty easily interpreted to mean what I thought it meant, I disagree with the advice of that interpretation.
| [reply]
[d/l] |
It certainly seems from reading the above that Jesse was, in 2001 at least, advocating putting the entire codebase, or nearly so, for an application in a single file.
He's arguing for putting all of the controller code for one application into a single file. I can't see anything to disagree with about that. He doesn't say "jam all of your applications for a whole site into one file" nor does he say "put all the database code and templates into one file." I understand what you're objecting to, but it isn't a view supported by Jesse or any of the current CGI::Application developers.
| [reply] |
