2.1. Bootstrap and Configuration

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:

// Solar system directory
$system = dirname(dirname(__FILE__));

// set the include-path

// load Solar
require_once 'Solar.php';

// start Solar with system config file
$config = "$system/config.php";

// instantiate and run the front controller
$front = Solar_Registry::get('controller_front');

// Done!

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.

2.1.1. The Solar::start() Method

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, and Solar_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 the Solar 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, and response. These refer to instances of Solar_Inflect, Solar_Locale, Solar_Request, and Solar_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.

[Note] 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 Solar_Registry::get().

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() defines several registry entries incurs very little performance reduction by itself.

2.1.2. Configuration

The Solar::start() method takes one parameter, a string indicating the path to a configuration file. In the standard Solar system, this is the SYSTEM/config.php file.

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] 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.