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] |
I think I see where we were talking past one another. I consider most of the sites I design to be one big, integrated application with several related modules. If you have a bunch of separate smaller applications on the same site, I can get behind that idea. You might consider what I'm talking about as a large application as several independent but related applications that happen to use the same classes, templates, user records, application data, and session information across them.
| [reply] |