Zend Framework Tutorial
By Lyndon Baptiste2008-08-13
Let's take a lot at index.php, the bootstrap file for the application firstly.
<?php
//coder can also set include paths rather than modify php.ini
set_include_path(
get_include_path() . PATH_SEPARATOR .
'./library' . PATH_SEPARATOR .
'./application' . PATH_SEPARATOR .
'./application/models'
);
require_once 'Zend/Cache.php';
require_once 'Zend/Config/Ini.php';
require_once 'Zend/Controller/Front.php';
require_once 'Zend/Db.php';
require_once 'Zend/Db/Table.php';
require_once 'Zend/Layout.php';
require_once 'Zend/Registry.php';
$config = new Zend_Config_Ini('./application/config.ini', 'production');
//db config and connect
$params = array(
'host' => $config->database->host,
'username' => $config->database->username,
'password' => $config->database->password,
'dbname' => $config->database->name
);
$db = Zend_Db::factory($config->database->type, $params);
Zend_Db_Table::setDefaultAdapter($db);
//cache
$frontendOptions = array('lifetime' => $config->cache->maxLifetime, 'automatic_serialization' => true);
$backendOptions = array('cache_dir' => $config->cache->dir);
$cache = Zend_Cache::factory('Core', 'File', $frontendOptions, $backendOptions);
//layout
$options = array(
'layout' => 'default',
'layoutPath' => './application/layouts',
'contentKey' => 'content',
);
Zend_Layout::startMvc($options);
//registry set
Zend_Registry::set('db', $db);
Zend_Registry::set('cache', $cache);
Zend_Registry::set('config', $config);
//dispatch
$front = Zend_Controller_Front::getInstance();
$front->addModuleDirectory('application/modules');
$front->dispatch();
?>
We can begin by setting the include path for our library, application and model files in the event we do not wish to make changes to php.ini. This enables us to require what I consider to be the core Zend Framework files from lines 10 to 16. Respectively files have been included which will enable us to perform caching, application wide configurations (handy for database password), routing of request in an Model View Controller environment, connecting to our choice of database, direct access to table information via the table data gateway pattern through inheritance, the ability to easy switch templates and the registry of variables in a manner the global keyword allows.
In line 18 the execution of the statement
$config = new Zend_Config_Ini('./application/config.ini', 'production');
will open a connection to a configuration file config.ini which can be formatted by using the nested object property syntax. The second parameter to the constructor is the section of the configuration file which we wish to load, in this case production. The great thing is that because our test environment may be slightly different to production we can inherit and override the necessary variables (For a more detailed discussion on this see the Zend_Config_Ini documentation). So what does the content of our config.ini file look like? See Figure 2. After a successful instantiation what we'll have $config, an object, loaded with the configuration items now as its properties. In light of this to access the name of the database the programmer will do so through $config->database->name. The depth of the configuration items is not limited to any number, however it will be simple if it remained shallow.
Lines 20 to 28 of index.php looks like this
//db config and connect
$params = array(
'host' => $config->database->host,
'username' => $config->database->username,
'password' => $config->database->password,
'dbname' => $config->database->name
);
$db = Zend_Db::factory($config->database->type, $params);
Zend_Db_Table::setDefaultAdapter($db);
A few important things are happening here. In line 21 an associative array of database configuration items have been created. The keys 'host', 'username, 'password' and 'dbname' are required and will relate to the setting for the database server you have installed. These items were stored in the config.ini file located in the application directory. In Line 27 a factory method was used. The first parameter specifying the desired database type. The documentation for Zend_Db specifies the various adapters which can be used. The second is the database configuration array that was previously set up. For those interested a Zend_Config object can also be passed as a parameter to the factory method. See the documentation for more details.
Line 28 invokes a call to a static method belonging to Zend_Db_Table. To touch a bit on Zend_Db_Table, the class is an object-oriented interface to database tables. It provides methods for many common operations on tables. The base class is extensible, so you can add custom logic. The model which we will be writing later on will need to be aware of the database object being used to retrieve the necessary information. We can do this in various ways, however perharps the most suitable way is to set it in the bootstrap file. As a result we wouldn't need to do this for various model classes later on.
From line 30 to 33 the cache is set up. The featured code is as follows:
//cache
$frontendOptions = array('lifetime' => $config->cache->maxLifetime, 'automatic_serialization' => true);
$backendOptions = array('cache_dir' => $config->cache->dir);
$cache = Zend_Cache::factory('Core', 'File', $frontendOptions, $backendOptions);
The frontend and backend configuration items are set up such as the lifetime of each cached item and whether or not serialisation should be automatic (we may need to cache objects such as a list of countries so serialisation becomes important). For the backend configuration options because for the purpose of this tutorial caching is in files rather than against a database the cache directory is set up. One line 33 the cache object is created using the static factory method. There are other configuration options available. For a list see the ZF documentation.
For those interested in having various layouts and how it can be implemented in a MVC environment lines 35 to 42 will be of most interest. The programmer can create an associative array specifying the default layout to use, the path to the layout scripts and the content key. This content will be interpreted as what should be rendered when our view scripts are called. Pretty cool huh? This means that your view scripts will have nothing beside the code for the current page! Line 42 is where Zend_Layout is enabled with the configuration array in a MVC environ.
Zend_Registry is simply a container for storing objects and values in the application space. More than likely you're going to want access to the database connection, cached object and configuration values later on so setting them in the bootstrap is a good idea. You can add any variable which qualifies using the static set method which takes two parameters, the key to store the variable under and the actual variable.
In a MVC environment the front controller handles the dispatching of work to the appropriate controller. This doesn't just happen magically. Code is required and various naming conventions must be followed to ensure that this is properly done (we will see how later on in the tutorial). The static method getInstance is used to retrieve the front controller. The programmer must set the module directory as shown in line 49 and then dispatch the work like a traffic cop through a call to the dispatch method.
Tutorial pages:
|
|
|||||||||
You might also want to check these out:
|
Link to This Tutorial Page!
