Modular architecture

Rather than being a large application, Magento is built by smaller modules, each adding specific functionality to Magento.

One of the advantages of this approach is the ability to enable and disable specific module functionality with ease as well as adding new functionality by adding new modules.

Autoloader

Magento is a huge framework composed by close to 20,000 files. Requiring every single file when the application starts would make it incredibly slow and resource intensive. Hence, Magento makes use of an autoloader class to require the files each time a factory method is called.

So what exactly is an autoloader? PHP5 includes a function called __autoload(). When instantiating a class, the __autoload() function is automatically called. Inside this function, the custom logic is defined to parse the class name and require the file.

Let's take a closer look at the Magento Bootstrap code located in app/Mage.php:

… 
Mage::register('original_include_path', get_include_path());
if (defined('COMPILER_INCLUDE_PATH')) {
    $appPath = COMPILER_INCLUDE_PATH;
    set_include_path($appPath . PS . Mage::registry('original_include_path'));
    include_once "Mage_Core_functions.php";
    include_once "Varien_Autoload.php";
} else {
    /**
     * Set include path
     */
    $paths[] = BP . DS . 'app' . DS . 'code' . DS . 'local';
    $paths[] = BP . DS . 'app' . DS . 'code' . DS . 'community';
    $paths[] = BP . DS . 'app' . DS . 'code' . DS . 'core';
    $paths[] = BP . DS . 'lib';

    $appPath = implode(PS, $paths);
    set_include_path($appPath . PS . Mage::registry('original_include_path'));
    include_once "Mage/Core/functions.php";
    include_once "Varien/Autoload.php";
}

Varien_Autoload::register();

The Bootstrap file takes care of defining the include paths and initializing the Varien autoloader, which will in turn define its own autoload function as the default function to call. Let's take a look under the hood and see what the Varien's autoload function is doing:

    /**
     * Load class source code
     *
     * @param string $class
     */
    public function autoload($class)
    {
        if ($this->_collectClasses) {
            $this->_arrLoadedClasses[self::$_scope][] = $class;
        }
        if ($this->_isIncludePathDefined) {
            $classFile =  COMPILER_INCLUDE_PATH . DIRECTORY_SEPARATOR . $class;
        } else {
            $classFile = str_replace(' ', DIRECTORY_SEPARATOR, ucwords(str_replace('_', ' ', $class)));
        }
        $classFile.= '.php';
        //echo $classFile;die();
        return include $classFile;
    }

The autoload class takes a single parameter called $class, which is an alias provided by the factory method. This alias is processed to generate a matching class name that is then included.

As we mentioned before, Magento's directory structure is important due to the fact that Magento derives its class names from the directory structure. This convention is the core principle behind factory methods, which we will be reviewing later in this chapter.

Code pools

As mentioned before, inside our app/code folder, we have our application code pided into the following three different directories known as code pools:

• core: This is where the Magento Core modules that provide the base functionality reside. The golden rule among Magento developers is that you should never, under any circumstance, modify any files under the core code pool.
• community: This is the location where third-party modules are placed. They are either provided by third parties or installed through Magento Connect.
• local: This is where all the modules and code developed specifically for this instance of Magento reside.

The code pools identify where the module came from and in which order they should be loaded. If we take another look at the Mage.php Bootstrap file, we can see the order in which code pools are loaded:

    $paths[] = BP . DS . 'app' . DS . 'code' . DS . 'local';
    $paths[] = BP . DS . 'app' . DS . 'code' . DS . 'community';
    $paths[] = BP . DS . 'app' . DS . 'code' . DS . 'core';
    $paths[] = BP . DS . 'lib';

This means, for each class request, Magento will look in the local folder, then in the community and core folders, and finally inside the lib folder.

This also produces an interesting behavior that can easily be used to override core and community classes by just copying the directory structure and matching the class name.

Tip

Needless to say, this is a terrible practice, but it is still useful to know about, just in case someday you have to take care of a project that exploits this behavior.