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