Good Mod_perl programming Simple Application Example Introduction _ Basic Course

Introductory Guide
Mod_perl is a huge and complex tool that builds a number of modules to help you easily build dynamic Web sites. The purpose of this guide is to help you build a good mod_perl module and understand the implementation techniques of mod_perl. I do not recommend using the techniques described here to build a large site, especially for someone who has just dabbled in mod_perl. But I recommend that you take a closer look at some of its built-in solutions, such as Mason, Axkit, Embperl, apache::asp and Pagekit, among others.
What do you need?
This guide assumes that you have had experience installing and testing mod_perl. and the newer version of Apache's installation experience. Because it is possible that you need to implement it on your machine to modify the configuration provided in this article. We need you to install some modules and need to enter the Apache configuration directory for modification. So it's best if you have root privileges to do these things. And of course you need a text editor.
Cut to the chase.
The Mod_perl module is also a Perl module, but it has a more specific design. The easiest way to create a Perl module is to use standard Perl to distribute your own tools H2xs. You can type H2xs in the command line mode to see its argument list. Now, to start a new project in an appropriate directory, type: H2xs-ax-n apache::tutorial::firsth2xs will create the directory Apache, as well as some other subdirectories. Now go to the deepest level of the catalogue look: CD apache/ Tutorial/first in this new catalogue, you can see 6 files: README, Changes, first.pm, MANIFEST, makefile.pl, and apache-tutorial-first.t. Their role is as follows:
Readme
This file contains some installation information, module dependencies, copyright information, etc.
Changes
This file is used as a modification log (changelog) file for your project
first.pm
This is the main module file that contains your Mod_perl handle code (handler).
MANIFEST
This file is used to automatically build a tar.gz type of module version distribution. This way you can get your module to CPAN or distribute it to someone else. It contains a list of all the files you have in this project.
makefile.pl
This is the standard Perl Makefile constructor. Used to create the makefile.pl file to compile the module.
apache-tutorial-first.t
Some test scripts for the module. By default it simply checks the loading of the module and you can add some new test cells. OK, now we're starting to turn first.pm into a working mod_perl module. Open the file using a text editor, as follows:
Package Apache::tutorial::first;
Use strict;
Use VARs qw/$VERSION/;
Use apache::constants;
$VERSION = 0.01;
Sub handler {
my $r = shift;
$r->send_http_header (' text/html ');
Print
"return OK;
}
1;
Don't forget the "1;" at the end of the file, and for Perl, a non-0 value returned by a module that indicates that the module has been successfully compiled.
Install your module
The H2xs tool makes our module installation work extremely convenient. In the same directory as your first.pm file. Type:
Perl makefile.pl
Make
Make test if make test succeeds, you need to perform as root:
Make install so you can install your module into the Perl Library directory.
Add a handle to Apache for this module (handler)
Now we need to go into the Apache configuration directory to modify the configuration file so that our module acts as a processor in the Apache content processing phase. Open the httpd.conf file and add the following configuration at the end:
<Location/mod_perl_tutorial>
SetHandler Perl-script
Perlhandler Apache::tutorial::first
Then save the configuration file and restart the Apache server:
Apachectl stop
Apachectl start now uses a browser to access http://localhost/mod_perl_tutorial, and you will see the "Hello World" page as expected.
When Apache starts, it reads its configuration instructions and passes the appropriate commands to the corresponding module that handles the command. Here are two related directives SetHandler and Perlhandler.
The first instruction SetHandler is handled by the Mod_mime module, which indicates what module is used as the main part of the processing request. The Perl-script set here represents the use of Mod_perl to process requests.
The second instruction Perlhandler is handled by the Mod_perl module, which is simply a description of using our module to handle the main part of the request. It is important to note that whenever you have a perlhandler, you need the corresponding SetHandler perl-script configuration instructions. This will make your Mod_perl code work. I always think this is a weakness, but this will involve the internal processing mechanism of Apache, so in the future it is very difficult to change.
Now that the request is here, Apache looks at what module is used to process the corresponding URI and decides to use mod_perl here, and Mod_perl knows that it must send the request to our module and call our module's handler () function as Apache::request The first parameter of the object. And the return value of our handler () function determines what the next step will be for Apache. Now we know that the return value OK means everything succeeds. OK is a constant that is exported from the Apache::constants module.
Debugging
If you don't see "Hello world", you may see a wrong page, or something completely different. The first step is to check the error log to see what is wrong. I am accustomed to viewing the error log immediately after requesting it in the browser. You can use the tail tool: Tail-f/path/to/apache/logs/error_log (Use your real error_log path to replace the path above). If you're not sure where it is, check out the ErrorLog instruction section of your httpd.conf file.
Now reload the page and Error_log will tell you where the problem occurs. For more about Perl debugging, see Perldebug.
Add more
Now if you want to make some changes to the above situation, how do you do it? Unfortunately, the only installation mode is as follows:
Modify your first.pm file
Re-run make install as root
Restart Apache
This may be a hassle, especially if you restart Apache. To solve this problem, we can install a specially designed module to avoid the hassle of doing it every time. First you need to download and install the Apache::reload module from CPAN (unless you already use mod_perl 1.26 or later). Here http://search.cpan.org/search?dist=Apache-Reload download.
Unlock the tar.gz file and go to the new directory and execute:
Perl makefile.pl
Make and execute to root:
Make install now opens the httpd.conf file again and joins:
Perlinithandler Apache::reload This will test all the changed modules and automatically reload the new modules if necessary. This is useful for development, but there is a performance penalty, so after the development is complete, the attribute is turned off.
Read more
There are a lot of things you need to do from here. The Apache API itself is huge, and most of them can see the appropriate documentation via Perldoc Apache. Now this module is basically worthless because only one URI can be used by the module (http://server/mod_perl_tutorial), which makes it less flexible. In order for a module to handle multiple URIs, there are many solutions, but the best recommendation is to use Apache::D ispatch module.
You can download Http://search.cpan.org/search?dist=Apache-Dispatch in CPAN. Apache::D Ispatch allows you to retain the standard Mod_perl handler architecture while allowing multiple functions and multiple URIs to be distributed.
Next, I don't recommend outputting content directly to the browser as in the example. Consider using some of the most commonly used template technologies, such as Template-toolkit, html::template, rather than using XSLT or xpathscript (there are many of these template technologies available, We hope one day there will be articles to discuss these techniques to help you choose.