mite isn’t so much a dedicated application as it is a collection of directory structures, modules, and implementation philosophy. Here are some of the basics of how it works, and why.
Current mite deployments have a the following directory structure at its most basic :
/config has at least one file names config.txt. This file provides the database connection info needed for the mite scripts to pull their basic configuration information. Previous versions used this as the actual configuration method for all settings, but that was updated recently to allow full configuration control via database tables.
The /data directories contain the controllers and views used by the main script. The view directory will contain files with template toolkit code, while the controller directory has any actual perl code needed for a given task.
The /lib directory contains any modules that are needed and remain local to the script(s). If the modules are installed into @INC, then this isn’t strictly needed
/web is the public directory hosted by the webserver (usually apache). This will have the main script within it, typically named act.pl, though this can be anything as long as the apache config specifies it.
mite was designed to run as a virtual host in apache, although with some tweaking there isn’t a reason this couldn’t be changed to meet specific needs. Here is a typical apache configuration for a mite based virtualhost :
Here are the important parts that allow mite to operate :
“DirectoryIndex act.pl” – this was the main script is the file used whenever unspecified
“AddHandler cgi-script .pl” – treat .pl files as CGI scripts
The rewrite block handles clean URLs by passing any requests not found as a file on disk to the script. The entire requested path is handed off as a parameter named ‘req’. With this in place, mite is able to avoid using query strings and forms for every action, and can instead map URL paths to functions.