Mangento init process

 

Magento init process bare essentials

Posted by branko in Magento | Comments Off

This
article is meant to be a start up point for “newbies” getting ready to
digg seriously into the Magetno. When I say newbie’s, I meant no
disrespect, I only ment new to Magento. Because, you cannot be newbie
PHP developer and do something usefull with Magento since it requires
extensive knowledge of OOP and MVC.

Step 1: Init/Run the Magento

File:
/index.php

Code (from line 52):

Mage::run();

Eplanation:
Mage is the class name of the /app/Mage.php file. Mage class is of type final, meaning you cannot extend it. In the code above, we are calling the static method run() on the Mage class.

Step 2: Overview of static run() method

File:
/app/Mage.php

Code (from line 447):

public static function run($code = '', $type = 'store', $options=array()){    try {        Varien_Profiler::start('mage');         Varien_Profiler::start('mage::app');        self::app($code, $type, $options);        Varien_Profiler::stop('mage::app');         Varien_Profiler::start('mage::dispatch');        self::app()->getFrontController()->dispatch();        Varien_Profiler::stop('mage::dispatch');         Varien_Profiler::stop('mage');    }    ... /* exception handling code here, irrelevant for this example */}

Explanation:
Inside run() method of Mage class two important things happen at the grand scale of things. Feel free to ignore the Varien_Profiler::start() and Varien_Profiler::stop()
at this point since they are irrelevant for this base introductory.
Those two important things I mentioned are two method calls insied this
run() method, and those are:

• self::app($code, $type, $options); /* on line 453 */
• self::app()->getFrontController()->dispatch(); /* on line 457 */

Both of these method calls point us to the same base method, so let’s disect that in next step.

Step 3: Overview of self::app() method

File:
/app/Mage.php

Code (from line 416):

public static function app($code = '', $type = 'store', $options=array()){    if (null === self::$_app) {        Varien_Profiler::start('mage::app::construct');        self::$_app = new Mage_Core_Model_App();        Varien_Profiler::stop('mage::app::construct');         Mage::setRoot();        Mage::register('events', new Varien_Event_Collection());          Varien_Profiler::start('mage::app::register_config');        Mage::register('config', new Mage_Core_Model_Config());        Varien_Profiler::stop('mage::app::register_config');         Varien_Profiler::start('mage::app::init');        self::$_app->init($code, $type, $options);        Varien_Profiler::stop('mage::app::init');         self::$_app->loadAreaPart(Mage_Core_Model_App_Area::AREA_GLOBAL, Mage_Core_Model_App_Area::PART_EVENTS);    }    return self::$_app;}

Explanation:
Inside app() method we have several essentials things happening. Try to ignore the Varien_Profiler::start() and Varien_Profiler::stop() stuff. Now let’s review the code. First we have self::$_app = new Mage_Core_Model_App() called, saying store me and instace of Mage_Core_Model_App into my local (from the point of view of Mage class) $_app variable.

Note the definition of app() method, it’s app($code = ”, $type = ‘store’, $options=array()).
It receives three main parameters (or none, in which case it uses
defaults). Anyhow, this method call sets up entire object of type Mage_Core_Model_App and stores it in Mage class local variable $_app.

Then we have three method calls, one after other setting up page Mage class object:

• Mage::setRoot();
• Mage::register(‘events’, new Varien_Event_Collection());
• Mage::register(‘config’, new Mage_Core_Model_Config());

After which we are pointed back to our Mage_Core_Model_App object instance by following method calls:

• self::$_app->init($code, $type, $options);
• self::$_app->loadAreaPart(Mage_Core_Model_App_Area::AREA_GLOBAL, Mage_Core_Model_App_Area::PART_EVENTS);

Note that self::$_app is storing the instace of Mage_Core_Model_App so it’s perfectly ok to call any public method that Mage_Core_Model_App class has on this variable.

I will not go into the details of what both of those method calls
do, since this article would take hours and hours to be written in such
a way to cover all the inner workings details.

For now, let’s just remember the return type of app() method call, return self::$_app, it’s the instance of Mage_Core_Model_App class. In short, app() method sets up and returns entire App model.

Now, let’s have a look back to step 2. There is one more method call left to be covered, we’ll do that in step 4

Step 4: Overview of self::app()->getFrontController()->dispatch()

File:
/app/code/core/Mage/Core/Model/App.php

Code (from line 857):

public function getFrontController(){    if (!$this->_frontController) {        $this->_initFrontController();    }     return $this->_frontController;}

Explanation:
Mage_Core_Model_App class is all about setting currently running application instance options. Method call getFrontController() returns the result of the private Mage_Core_Model_App method called _initFrontController().

While the _initFrontController() calls and sets $this->_frontController = new Mage_Core_Controller_Varien_Front(), where $this variable is in context of Mage_Core_Model_App class, it returns $this, or in short, it returns current instace of Mage_Core_Model_App class.

Since self::app()->getFrontController() method call returned us and object instance of type Mage_Core_Model_App we are allowed to chain a method dispatch() to it. Since this is the last method call inside run() method of a Mage class file, this makes it a full circle.

Keep in mind that this is really, really, really the most basic intro
to Magento’s init process. There are a ton of stuff that happen upon
each method call in this process and I only covered the most basic one.
For instance, when you called the self::app() you “triggered chained” calls of many methods that might call other classes and methods essential to build a instance of Mage_Core_Model_App. Not to mention the inheritance and so on.

I find it a pencil and a piece of paper to be a good tools for
tracking and “drawing” yourself Magento application inner workings.
Core things are really massive, a lot of file are involved into the
Magento init process and lover core inner workings. It gets easy to
loose track of things jumping from one class to another.