When a client makes a request against a Solar system for a resource
that isn't in the filesystem, that request gets routed to the bootstrap
index.php script. The standard Solar system
bootstrap script is very small, but it does a lot:
<?php // Solar system directory $system = dirname(dirname(__FILE__)); // set the include-path set_include_path("$system/include"); // load Solar require_once 'Solar.php'; // start Solar with system config file $config = "$system/config.php"; Solar::start($config); // instantiate and run the front controller $front = Solar_Registry::get('controller_front'); $front->display(); // Done! Solar::stop();
All the heavy lifting for the bootstrap is done by the
Solar::start() method. This sets up the
Solar system environment for us. Once that is done, it invokes
a front controller and tells the front controller to display the
result of its activity.
We'll talk more about the front controller in a moment. Before we do,
let's look at what
Solar::start() does in more
depth, and how the configuration file is put together.
In order, the
Solar::start() method does these
things to set up the environment.
Solar_Class::autoload()as an SPL autoloader.
As a security measure, cleans the superglobal arrays so that variables don't get overwritten by incoming user values.
Solar_Config::load()to read in configuration values and make them available to classes for self-configuration, and sets some values and configuration for the
ini_setusing the values from the
Solar_Registryentries for all items from the
If they do not exist already, adds registry entries for the names
response. These refer to instances of
Finally, run any "hook" scripts, functions, or methods specified by the
['Solar']['start']configuration key. These let you specify behaviors and logic to be executed at the end of the startup routine.
|What's A Registry? Isn't That A Lot Of Objects?|
The registry is a place to store instances of objects so they can be
used by the system as a whole without having to pass them around
as parameters to methods. Registry objects are stored and retrieved
using unique names; any object in the registry can be retrieved
Registry objects are lazy-loaded. That means you can define an
object to go into the registry, but it won't be instantiated
until you attempt to retrieve it. Thus, the fact that
Solar::start() method takes one parameter,
a string indicating the path to a configuration file. In the
standard Solar system, this is the
config.php file is like any other PHP
script. You can use the full range of PHP commands, build in
conditionals and loops, use includes, and so on. However,
Solar::start() expects the config file to
return an array; this is the configuration array.
In Solar, the classes read their own configurations out of this array when they are instantiated, and set themselves up using the values from that array as their defaults. For the classes to be able to pick out their configurations, the config array elements are keyed by class name; the element values are themselves arrays that get passed to the class constructor.