Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re^5: What is the Perl Web Framework du jour?

by mr_mischief (Prior)
on Mar 26, 2009 at 17:44 UTC ( #753469=note: print w/ replies, xml ) Need Help??

in reply to Re^4: What is the Perl Web Framework du jour?
in thread What is the Perl Web Framework du jour?

The modules concern is'nt that a hosting provider doesn't let you install modules. Those providers should never be even considered. It's that some hosting providers have methods for doing so, but that their methods create unpleasant overheads. Some let you install modules for the single site itself, but then you have to do bugfix updates for every site individually even though they're on the same server. Others will let you request a module to add server-wide, but they make you request each one individually or take a while to give the response. Still others let you install in one place for all your sites without interfering with other customers of theirs even without a VPS or a full server, and that's great. A VPS or full server hosting arrangement of course shouldn't pose any problems.

The advice to keep an entire application together in one place was actually an article published by O'Reilly on several years back (2001, to be exact). It's this one, written by Jesse Erlbaum who is referenced many times on the project's web site (often by first name only). Now, I'll admit that web applications have grown on average past what was expected in 2001, and the advice makes more sense for small, simple applications than for larger, more complex ones. It's good to know you don't recognize that advice, because I'd hate to think it's still being given. It's bad enough it was given then.

Comment on Re^5: What is the Perl Web Framework du jour?
Re^6: What is the Perl Web Framework du jour?
by perrin (Chancellor) on Mar 26, 2009 at 18:20 UTC
    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.
      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.

        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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://753469]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (13)
As of 2014-07-28 17:29 GMT
Find Nodes?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:

    Results (204 votes), past polls