Understanding mod_Perl from HTTP and CGI I been involved with Perl and web programming since 1997. In these years many times i've been teaching web programming, beginning with HTTP, CGI, Perl and then mod_perl. For me it's hard to communicate something without drawings, so in these years I've made many white board sketching to explain web programming. This document resumes this sketches with some more explanations.Mod_perl is a very amazing technology, it's free it's GPL, i recommend it. The CPAN community has prebuilt modules almost for anything you may like, this can speed up your development with already made code and gives you the chance to share yours. Perl object model is extremely powerful and fun to program, please take a look at it. If you don't work in mod_perl, the basis explained in this document are applicable almost to any web technology used actually, no matter how much commercial solutions try to appear "very different and exclusive". You may think "this guy don't know other thing" ? ... the answer is no, i've developed web solutions in ASP, Java and PHP too, without naming the others languages i've been working preofessionally: I like Perl !! Before you begin, i must tell you my English is not very good, but i decided to make this first version in that language to get to a broader audience. The original document is inkscape SVG, that's why images are used too much, i expect to apply some css and layers to fix this, by the time: here is the original svg version. Year 1991, the HTTP protocol is created, urls defined, and user agents can retrieve remote HTML documents residing on a server hard disk using the HTTP protocol. 1993, the HTTP protocol is extended in order to allow execution of arbitrary programs to produce the response, a method is created for passing parameters to the programs through url or body of request. The response is not limited to documents on the server hard disk: "The output of any executable program can be the response to a request". 1996, a complete Perl interpreter is embedded in an apache C module, the Perl code executed under it, have a Perl View of the Apache C API and can alter an extend apache behavior in any way it likes. In some way mod_perl is not an specific solution, instead it's a framework for extending the apache web server. using the apache extension system but programmed in Perl not C, let's see more: In order to serve a request, the web server executes a predefined series of steps or phases. For every phase there is one or more handlers registered, eventually all handlers for a phase are executed. Handlers can be registered dynamically, or via the apache configuration file. For more on Apache Phases please google "the Apache Server Life Cycle". In this traditional apache operation mode, in order to add or extend functionality it's necessary to program a C module, compile and link it statically or dynamically with the web server, the module must define which phases it's going to handle. Normally in Apache Configuration file httpd.conf directives control module activation and behavior. The Perl Interpreter is inside a traditional Apache C module. This special (or generic) module is registered to handle all the Apache phases (normally modules register themselves to act on some specific phases, not all like mod_perl does). Configuration directives activate or deactivate the mod_perl module handling of phases. Configuration directives tell what package and subroutine inside that package will handle specific request. The Perl code running inside this module have a Perl view of the Apache API through a request object passed as parameter to the Perl subroutine called and accessible later through Apache->request call. We want a web page showing the date and time: For many years Perl was the workhorse of the dynamic web content on the Internet, that's why one of the first uses of mod_perl was to run these Perl CGI scripts under mod_perl faster, avoiding compilation & fork & exec. The module Apache::Registry was build for that. It creates and cache an in memory representation of the designated CGI script. First time it load from disk, next times it executes in memory execution image of the script. One of my primary occupations is web software development, in this section i will show how do I use mod_perl to build the dynamic, object/database backed web sites. mod_perl can be used in any ways: just build a module for the response phase and point to it like the SayTime example above, or use higher level tools, primary: - Frameworks for simple code+HTML style, like: Apache::ASP, Mason, Embperl. - Complex CMS Systems like Bricolage, OpenInteract or Metadot ..you choose your flavor, and there are many more, i like this "many ways to do web with mod_perl", but i think it's one of the reasons why people end using PHP, you don't have the first question when someone ask me how to do mod_perl � what toolkit to use ?, in the end using PHP or Java, people end using some kind of system, plain PHP or java JSP or servlets coding become a mess for big systems, and some kind of templating is needed. That said, i use my own method, it's almost plain mod_perl with templates, more specifically it can be defined like: "A front controller + UI Layer + templates + Domain Later + Database". All Transaction Handlers inherit from a Generic FormHandler module, the FormHandler module is a Facade, centralizes access to many services needed at UI layer: Template Parsing, UI Fields, Gallery's & Error Messages Control. The handler() method of FormHandler, is a Template Method (pattern) for handling Form submission like Services. General control flow goes like this: I expect this document help you to understand how mod_perl works in a very basic level. If you have any questions, feel free to contact me: Hans Poo, Web Developer & Linux Consultant http://hans.welinux.cl, cellular 09-319.93.05, office 56-2-6729318 Santiago, Chile This document is licensed under the terms of the GPL license. Document developed with inkscape. Hans Poo, Marzo 2005, hans@welinux.cl, Actualizado Marzo 2006. |