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.
-
Loads the baseline classes needed for operations:
Solar_Base
,Solar_Class
,Solar_Config
, andSolar_File
. -
Registers
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.
-
Calls
Solar_Config::load()
to read in configuration values and make them available to classes for self-configuration, and sets some values and configuration for theSolar
arch-class. -
Calls
ini_set
using the values from the['Solar']['ini_set']
configuration key. -
Makes
Solar_Registry
entries for all items from the['Solar']['registry_set']
configuration key. -
If they do not exist already, adds registry entries for the names
inflect
,locale
,request
, andresponse
. These refer to instances ofSolar_Inflect
,Solar_Locale
,Solar_Request
, andSolar_Http_Response
, respectively. -
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
using
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
|
The Solar::start()
method takes one parameter,
a string indicating the path to a configuration file. In the
standard Solar system, this is the
file.
SYSTEM
/config.php
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.
Note | |
---|---|
There are nuances and extensions to the configuration behaviors described here; for more information, consult the API docs for the Solar::start() method and the Solar_Config class. |