Per Einar Ellefsen wrote: > It's a good idea. You're right, it makes navigation pretty good. The only > thing that worries me is that it might take up too much space when applied > to *all* the headers.
i agree :) > Suggestion: > - we only use that breadcrumb for some headers: we probably don't need them > for Level 1 headers, but we could have them for atleast level 2, and maybe > level 3 headers. > - we add a horizontal rule before the level 1 header, as to separate > sections visually. i think the breadcrumb should be used everywhere or nowhere. with everywhere i of course mean where there's one or more "ancestor" links. i have tried to apply your suggestion into the enclosed file. i'm not so sure i like the rule across the page so many times, but on the other i really dont have a better soloution. well take a look again and see what you think. another thing i tried and that i'm unsure of, can be seen if you try to de-comment the comments at the top of the style specs (in div.toc and span.tocheader). this should produce a light gray box with a darkblue border around the toc-list. it may be too boxy and anyway it's just an idea to further seperate different parts of the page ... take a look. ./allanTitle: mod_perl Installation
A Summary of a Basic mod_perl Installation The following 10 commands summarize the execution steps required to build and install a basic mod_perl enabled Apache server on almost any standard flavor of Unix OS.
Of course you should replace x.xx and x.x.x with the real version numbers of mod_perl and Apache. All that's left is to add a few configuration lines to If you have stumbled upon a problem at any of the above steps, don't despair, the next sections will explain in detail each and every step. Of course there is a way of installing mod_perl in only a couple of minutes if you are using a Linux distribution that uses RPM packages:
or apt system:
These should set up both Apache and mod_perl correctly for your system. Using a packaged distribution can make installing and reinstalling a lot quicker and easier. (Note that the filenames will vary, and xx.xx will differ.) Since mod_perl can be configured in many different ways (features can be enabled or disabled, directories can be modified, etc.) it's preferable to use a manual installation, as a prepackaged version might not suit your needs. Manual installation will allow you to make the fine tuning for the best performance as well. In this chapter we will talk extensively about the prepackaged versions, and ways to prepare your own packages for reuse on many machines. The Gory Details We saw that the basic mod_perl installation is quite simple and takes
about 10 commands. You can copy and paste them from these pages. The
parameter To accomplish this you will need to understand various techniques for mod_perl configuration and building. You need to know what configuration parameters are available to you and when and how to use them. As with Perl, with mod_perl simple things are simple. But when you need to accomplish more complicated tasks you may have to invest some time to gain a deeper understanding of the process. In this chapter I will take the following route. I'll start with a detailed explanation of the four stages of the mod_perl installation process, then continue with the different paths each installation might take according to your goal, followed by a few copy-and-paste real world installation scenarios. Towards the end of the chapter I will show you various approaches that make the installations easier, automating most of the steps. Finally I'll cover some of the general issues that can cause new users to stumble while installing mod_perl. We can clearly separate the installation process into the following stages:
Source Configuration (perl Makefile.PL ...)
[
The Gory Details
]
Before building and installing mod_perl you have to configure it. You configure mod_perl just like any other Perl module:
In this section we will go through most of the parameters mod_perl can accept and explain each one of them. First let's see what configuration mechanisms we have available.
Basically they all define a special set of parameters to be passed to
The source configuration mechanism in Apache 1.3 provides four major features (which of course are available to mod_perl):
Taking these four features together provides a way to integrate mod_perl into Apache in a very clean and smooth way. No patching of the Apache source tree is needed in the standard situation and in the APXS situation not even the Apache source tree is needed. To benefit from the above features a new hybrid build environment was
created for the Apache side of mod_perl. The Apache-side consists of
the mod_perl C source files which have to be compiled into the
This approach is problematic in several ways. It is very restrictive and not very clean because it assumes that mod_perl is the only third-party module which has to be integrated into Apache. The new approach described below avoids these problems. It prepares only the src/modules/perl/ subtree inside the Apache source tree without adjusting or editing anything else. This way, no conflicts can occur. Instead, mod_perl is activated later (when the Apache source tree is configured, via APACI calls) and then it configures itself. We will return to each of the above configuration mechanisms when describing different installation passes, once the overview of the four building steps is completed.
Configuration parameters
The command
APACHE_SRC
If you specify neither the etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. Last modified Mon Apr 1 16:57:57 2002 | |||||||||||||||||
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
