hi [enclosing an example based on /dst_html/docs/1.0/guide/intro.html]
two issues: 1) the list problem 2) the toc issue 1) is "solved" using divs instead of <ul> and <li> tags. the problem (well, its only in netscape4 i think) is that when you apply a list-style of "none" it will show a question mark (?), why i don't understand, but it does. i have tried several tricks to solve that and it can be done but we have to use another stylesheet for netscape or opera or whatever etc. so enter the div solution. take a look and see what you think about it, i think it can be used in our case. 2) while working on the different headers-issues i also came up with the enclosed colour-scheme for the toc-section. the reason for introducing these colors here is twofold. a) simply to better seperate the toc from the content. b) indicate whether links inside that toc-section is visited (i forgot why we don't do that already) so the toc in this example is blue background. the links are white and the visited colour is the same red as always. the hovering is white underlined. it doesn't have to be these colours, but i like the combination (and they already belong to our current color-palette) please note that we can still maintain the list-style (the different disc-styles) if people prefer. lists will by default wrap long text more correctly. i just used the div solution here because it was relevant for issue 1) .) ./allanTitle: Introduction. Incentives. Credits.
Table of ContentsText 1
Text 2
Text 3 a very long text a very long text a very long text a very long text a very long text a very long text a a very long text a a very long text a a very long text a a very long text a a very long text a
Text 4
49 DescriptionAn introduction to what mod_perl is all about, its different features,
and some explanations of 50 What is mod_perlThe Apache/Perl integration project brings together the full power of the Perl programming language and the Apache HTTP server. With mod_perl it is possible to write Apache modules entirely in Perl, letting you easily do things that are more difficult or impossible in regular CGI programs, such as running sub requests. In addition, the persistent Perl interpreter embedded in the server saves the overhead of starting an external interpreter, i.e. the penalty of Perl start-up time. And not the least important feature is code caching, where modules and scripts are loaded and compiled only once, and for the rest of the server's life they are served from the cache. Thus the server spends its time only running already loaded and compiled code, which is very fast. The primary advantages of mod_perl are power and speed. You have full
access to the inner workings of the web server and can intervene at
any stage of request-processing. This allows for customized processing
of (to name just a few of the phases) URI->filename translation,
authentication, response generation, and logging. There is very little
run-time overhead. In particular, it is not necessary to start a
separate process, as is often done with web-server extensions. The
most wide-spread such extension, the Common Gateway Interface (CGI),
can be replaced entirely with Perl code that handles the response
generation phase of request processing. mod_perl includes two general
purpose modules for this purpose: You can configure your httpd server and handlers in Perl (using
Many people ask "How much of a performance improvement does mod_perl give?" Well, it all depends on what you are doing with mod_perl and possibly who you ask. Developers report speed boosts from 200% to 2000%. The best way to measure is to try it and see for yourself! (See http://perl.apache.org/tidbits.html and http://perl.apache.org/stories/ for the facts.) 50.1 mod_cgiWhen you run your CGI scripts by using a configuration like this:
you run it under a mod_cgi handler, you never define it explicitly. Apache does all the configuration work behind the scenes, when you use a ScriptAlias. By the way, don't confuse
50.4 Apache::RegistryFrom the viewpoint of the Perl API, To prevent script name collisions,
The last thing From the viewpoint of the programmer, there is almost no difference between running a script as a plain CGI script under mod_cgi and running it under mod_perl. There is however a great speed improvement, but at the expense of much heavier memory usage (there is no free lunch :). When they run under mod_cgi, your CGI scripts are loaded each time they are called and then they exit. Under mod_perl they are loaded once and cached. This gives a big performance boost. But because the code is cached and doesn't exit, it won't cleanup memory as it would under mod_cgi. This can have unexpected effects. Your scripts will be recompiled and reloaded by mod_perl when it detects that you have changed them, but remember that any libraries that your scripts might require() or use() will not be recompiled when they are changed. You will have to take action yourself to ensure that they are recompiled. Of course the guide will answer all these issues in depth. Let's see what happens to your script when it's being executed under
The first line provides a unique namespace for the code to use, and a unique key by which the code can be referenced from the cache. The second line imports The META: Complete 51 What will you learnThis document was written in an effort to help you start using
Apache's mod_perl extension as quickly and easily as possible. It
includes information about the installation and configuration of both
Perl and the Apache web server and delves deeply into the issues of
writing and porting existing Perl scripts to run under mod_perl. Note
that it does not attempt to enter the big world of using the Perl API
or C API. You will find pointers to coverage of these topics in the
guide::help/ section of this
document. This guide tries to cover the most of the
It is assumed that you know at least the basics of building and installing Perl and Apache. (If you do not, just read the INSTALL documents which are part of the distribution of each package.) However, in this guide you will find specific Perl and Apache installation and configuration notes, which will help you successfully complete the mod_perl installation and get the server running in a short time. If after reading this guide and the other documents listed in guide::help/ you feel that your questions remain unanswered, you could try asking the apache/mod_perl mailing list to help you. But first try to browse the mailing list archive (located at http://mathforum.org/epigone/modperl ). Often you will find the answer to your question by searching the mailing list archive, since most questions have already been asked and answered already! If you ignore this advice, do not be surprised if your question goes unanswered - it bores people when they're asked to answer the same question repeatedly - especially if the answer can be found in the archive or in the documentation. This does not mean that you should avoid asking questions, just do not abuse the available help and RTFM before you call for HELP. (You have certainly heard the infamous fable of the shepherd boy and the wolves...) And if you do ask questions on the mailing list please make your subject line descriptive of the problem, not just "Help" - you're far more likely to get replies if people can see the issue you are talking about straight away. If you find incorrect details or mistakes in my grammar, or you want to contribute to this document please feel free to send me an email at [EMAIL PROTECTED] . 52 High-Profile Sites Running mod_perlA report prepared by Rex Staples at Thu, 14 Oct 1999:
53 References and AcknowledgmentsI have used the following references while writing this guide:
I have quoted many snippets of information from FAQs and emails, but I have not credited each quote in the guide individually. I did not mean to take the credit for myself, it's just that I tried to keep track of names, and became lost, so instead of scattering credits throughout the Guide I have gathered them all together here. If you want your name to show up under your original quote, please tell me and I'll add it for you. Major contributors:
Credits of course go to ( alphabetically sorted ):
I want to thank all the people who donated their time and efforts to make this amazing idea of mod_perl a reality. This includes Doug MacEachern, the author of mod_perl, and all the developers who contributed bug patches, modules and help. And of course the numerous unseen users around the world who help to promote mod_perl and to make it a better tool. 54 MaintainersMaintainer is the person(s) you should contact with updates, corrections and patches.
55 Authors
Only the major authors are listed above. For contributors see the Changes file. Last modified Thu Apr 11 23:25:29 2002 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
