[ Thanks to Baiju Thakkar for this
link. ]
“In the previous article, we gave an overview of SkunkWeb’s
templating language (STML) and component system. This article picks
up where we left off to describe some of the other facilities
SkunkWeb provides for dealing with real-world web programming needs
such as managing database connections, authenticating users,
configuring virtual hosts, rewriting urls, managing user sessions,
and distributing products. As a foundation for discussing those
facilities, we must first take an in-depth tour of SkunkWeb’s
internal architecture.“If you look in the lib directory of a SkunkWeb installation,
you will see three subdirectories: SkunkWeb, Services, and pylibs.
This arrangement is not quite parallel; SkunkWeb is a package with
an __init__.py, and is imported as such, while the other two
directories are not, and are themselves added to sys.path. The
SkunkWeb package contains the core infrastructure of the SkunkWeb
server: bootloading, configuration, and process management. The
Services directory contains Python modules that are classified as
services; they generally have some dependency on the SkunkWeb
package or on some other service. The pylibs directory contains
Python modules that SkunkWeb may need, but which could also be used
outside of the SkunkWeb environment.“When the server is started, it reads a configuration file (by
default, <skunkroot>/etc/sw.conf where is the installation
directory), itself containing Python code, which is then executed
in the namespace of a special, somewhat magical object globally
available as SkunkWeb.Configuration. (This object pretends to be a
module, and is imported, but is actually an instance of the class
ConfigLoader.ScopeableConfig). The Configuration object is thereby
first populated with attributes; its quasi-magical properties will
be discussed a bit later…”