Re: titles all look the same

[allan]

hi

i don't have a proper solution for this. 
i see your point though i think the real issue for a user is
basically: "where am i?".


i have enclosed an example which might be too much but i
think the problem should be solved along those lines.

the file is a heavily heavily edited (to save kb) version of
/docs/1.0/guide/install.html. it should "run standalone" :)


what i have done, is:
- boldfaced the h1, h2, h3, h4 (which i think we should have
done anyway).
- included the path/breadcrumb for (_only_) this particular
item : APACHE_SRC
(the styles for this local path/breadcrumb is of course the
same as the one at the top of the page)


so what you get is first of all more visible section headers
(because they are bold) and secondly a complete path for the
current chosen item. with that path (and its links) close to you,
it's easier to see where you actually are and therefore
easier to navigate the content _and_ therefore easier to
understand the context.


well, click on APACHE_SRC in the table of contents and you
see what i mean.

this solution is not so visibly seperated as you requested,
but on the other hand it is user-friendly IMO. in fact,
having just taken a look at it again i think it looks rather
cool, also because it will (should) scale well if there's a
long path.  

./allan

Per Einar Ellefsen wrote:
> 
> Hi everyone,
> 
> I guess this is more a question for the design department :)
> 
> I have been working on the content quite a bit this week-end, and have
> become concerned with one thing: it's impossible to see any difference
> between the different title tags: <h1>, <h2>, <h3>, etc.. all look the
> same! This is a problem because it means you can't get an idea of the
> section hierarchy while reading the document, only in the TOC.
> 
> I suggest that you either:
> - make them different sizes
> - make them more or less emphasized
> - make them different colours (I prefer not, I think the colours is good as
> it is)
> 
> I actually like their look, but I think it should be possible to tell them
> apart.
> 
> --
> Per Einar Ellefsen
> [EMAIL PROTECTED]
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

Title: mod_perl Installation

Home / Documentation / mod_perl guide / mod_perl Installation Table of Contents Description A Summary of a Basic mod_perl Installation The Gory Details Source Configuration (perl Makefile.PL ...) Configuration parameters APACHE_SRC Description FIXME: DESCRIPTION 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. % cd /usr/src % lwp-download http://www.apache.org/dist/httpd/apache_x.x.x.tar.gz % lwp-download http://perl.apache.org/dist/mod_perl-x.xx.tar.gz % tar xzvf apache_x.x.x.tar.gz % tar xzvf mod_perl-x.xx.tar.gz % cd mod_perl-x.xx % perl Makefile.PL APACHE_SRC=../apache_x.x.x/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 % make && make test && make install % cd ../apache_x.x.x % make install 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 httpd.conf, the Apache configuration file, start the server and enjoy mod_perl. 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: % rpm -i apache-xx.xx.rpm % rpm -i mod_perl-xx.xx.rpm or apt system: % apt-get install libapache-mod-perl 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 EVERYTHING=1 selects a lot of options, but sometimes you will need different ones. You may need to pass only specific parameters, to bundle other components with mod_perl etc. You may want to build mod_perl as a loadable object instead of compiling it into Apache, so that it can be upgraded without rebuilding Apache itself. 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, Building, Testing and Installation. Source Configuration (perl Makefile.PL ...) Before building and installing mod_perl you have to configure it. You configure mod_perl just like any other Perl module: % perl Makefile.PL [parameters] 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 perl Makefile.PL. Depending on the chosen configuration, the final product might be a stand-alone httpd binary or a loadable object. The source configuration mechanism in Apache 1.3 provides four major features (which of course are available to mod_perl): Per-module configuration scripts (ConfigStart/End) This is a mechanism modules can use to link themselves into the configuration process. It is useful for automatically adjusting the configuration and build parameters from the modules sources. It is triggered by ConfigStart/ConfigEnd sections inside modulename.module files (e.g. libperl.module). Apache Autoconf-style Interface (APACI) This is the new top-level configure script from Apache 1.3 which provides a GNU Autoconf-style interface. It is useful for configuring the source tree without manually editing any src/Configuration files. Any parameterization can be done via command line options to the configure script. Internally this is just a nifty wrapper to the old src/Configure script. Since Apache 1.3 this is the way to install mod_perl as cleanly as possible. Currently this is a pure Unix-based solution because at present the complete Apache 1.3 source configuration mechanism is only available under Unix. It doesn't work on the Win32 platform for example. Dynamic Shared Object (DSO) support Besides Windows NT support this is one of most interesting features in Apache 1.3. Its a way to build Apache modules as so-called dynamic shared objects (usually named modulename.so) which can be loaded via the LoadModule directive in Apache's httpd.conf file. The benefit is that the modules are part of the httpd executable only on demand, i.e. only when the user wants a module it is loaded into the address space of the httpd executable. This is interesting for instance in relation to memory consumption and upgrading. The DSO mechanism is provided by Apache's mod_so module which needs to be compiled into the httpd binary. This is done automatically when DSO is enabled for module mod_foo via: ./configure --enable-module=foo or by explicitly adding mod_so via: ./configure --enable-module=so APache eXtenSion (APXS) support tool This is a new support tool from Apache 1.3 which can be used to build an Apache module as a DSO even outside the Apache source-tree. One can say APXS is for Apache what MakeMaker and XS are for Perl. It knows the platform dependent build parameters for making DSO files and provides an easy way to run the build commands with them. (MakeMaker allows an easy automatic configuration, build, testing and installation of the Perl modules, and XS allows to call functions implemented in C/C++ from Perl code.) 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 httpd program. They are usually copied to the subdirectory src/modules/perl/ in the Apache source tree. To integrate this subtree into the Apache build process a lot of adjustments were done by mod_perl's Makefile.PL in the past. And additionally the Makefile.PL controlled the Apache build process. 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 perl Makefile.PL, which is also known as a "configuration stage", accepts various parameters. In this section we will learn what they are, and when should they be used. APACHE_SRC [ The_Gory_Details / Source Configuration (perl Makefile.PL ...) / Configuration parameters ] If you specify neither the DO_HTTPD nor the NO_HTTPD parameters you will be asked the following question during the configuration stage: etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. etc. Use of the Camel for Perl is a trademark of O'Reilly & Associates, and is used by permission. Last modified Mon Apr 1 16:57:57 2002

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]