Actions

Actions are classes that extend Mage_Core_Controller_Front_Action which, in turn, extends Mage_Core_Controller_Varien_Action. Actions also have a dispatch method, but this method dispatches the request to an action method. Action methods have the word “Action” appended to their names to distinguish them from normal class methods. Appending a word to the method name also helps to stop people from running unexpected methods from the URL. Imagine someone requesting example.com/index.php/customer/account/__destruct. If the system did not protect action names, the resulting method call would look something like this:

$controllerInstance->__destruct();
Something like this could potentially be a vector to open up attacks on your site.

But, I digress,Magento does protect the action method names by appending Action to any value taken from the URL, so this argument is purely academic.
During the dispatch event, the preDispatch method is called, and following the actual execution of the action method, the postDispatch method is called. By default, the postDispatch will save the current URL into the user’s session as the last URL visited.
Action and action methods arewhere the primary business logic for a request happens. Typically the action methods will load a model or two based on IDs or other URL parameters, kick off a few methods of these models, and then run the layout sequence. Having the action methods be responsible for outputting their own layout is an important issue to understand. This makes it more difficult to integrate with other systems, as you cannot as easily supplant your own layout or templating methods after executing the business logic. Also, it does not allow for any “post dispatch” logic to make any alterations to the output.

Routers

Once a router has found a match of the first part of the URL to a defined frontName value from the XML, this value gets directly translated into a module name with a little adjustment to the capitalization of the words. The controller and the action names are taken from the URL as diagrammed above. If any value is missing, the defaults are taken from the core XML config via the getDefault method. When specifying a URL, you don’t always specify exactly which module, controller, and action you want to run. A request to example.com/customer/ does not fully specify which controller of the customer module, nor which action to run. If any indicators of module, controller, or action are missing from the URL the values are read from the default tag under web, then under front (default/web/front).

By default, the CMS supplies these XML values it its own config.xml file. You can change these values in the administrative back-end under the menu items System > Configuration > Web. If the XML values happen to be completely missing, the fall-back values of core, index, and again, index are used for the values of module, controller, and action, respectively.

The Front Controller

From here, the responsibility transfers to the front controller. The front controller has an array of “routers” that it uses to decide which module the URL should trigger. This correlation between URL and module name is defined in the config.xml files. The available routers are:
• Standard
• Admin
• Default (only used for 404s)
The definition of a match between a router and amodule looks like this for the Customer module:

<routers>
<customer>
<use>standard</use>

<args>
<module>Mage_Customer</module>
<frontName>customer</frontName>
</args>
</customer>
</routers>

The AppModel

The “App” model is the main kickoff point for the execution path of any request to Magento. Although the Mage class is important for loading all sorts of classes and configurations, the execution path starts and ends inside the App. The App is responsible for:
• Initializing the system cache
• Instantiating the default front controller (Mage_Core_Controller_Varien_Front)
• Instantiating the default request object (Mage_Core_Controller_Request_Http)

Magento’s Request Cycle

Now we will discuss how a browser request to a URL gets translated into module execution. Generally speaking, any URL can be deconstructed like this:

Magento’s request cycle can be a little confusing to trace through. This is mostly due to the hierarchical nature of the file nesting (routers located under controllers) and the use of the term “dispatch” to mean 3 different things. The front controller “dispatches” the request to its internal list of “routers” and determines if any of the routers “match()” the request’s parameters. If so, then a new MVC Controller (not front-controller) is created from the matching module and, again, the request is “dispatched” to this controller object. The final MVC-style controller is technically a “Front Action”, it houses a number of methods that define the business logic tier.
This new Action object dynamically calls one of its own action methods and marks the request as being “dispatched” (i.e. finished). All these uses of “dispatch” are still different from the event mechanism’s dispatchEvent() method.

This directory listing shows all the files (except base Zend Framework files) that
are involved in dispatching a request to the proper module. The directory layout has
nothing to do with the class hierarchy, it is simply a product of class naming and
PHP’s autoloading capabilities.
Core
|- Controller/
| |- Front/
| | |- Action.php
| | ‘- Router.php
| |- Request/
| | ‘- Http.php
| |- Response/
| | ‘- Http.php
| ‘- Varien/
| |- Action.php
| |- Front.php
| ‘- Router/

| |- Abstract.php
| |- Admin.php
| |- Default.php
| ‘- Standard.php