Q: A custom frontend controller will extend which one of the following classes?

All Action Controller need Mage_Core_Controller_Front_Action as an ancestor.

The best example of this in action is a simple HelloWorld module that is configured with routes and has a Create Action Controller for the routes.

Directory Structure:

app/code/local/nodwell/Helloworld/Block
app/code/local/nodwell/Helloworld/controllers
app/code/local/nodwell/Helloworld/etc
app/code/local/nodwell/Helloworld/Helper
app/code/local/nodwell/Helloworld/Model
app/code/local/nodwell/Helloworld/sql

We need a configuration file (PATH: app/code/local/nodwell/Helloworld/etc/config.xml):


<config>    
    <modules>
        <nodwell_Helloworld>
            <version>1.0.0</version>
        </nodwell_Helloworld>
    </modules>
</config>

and a modules file to activate our module (PATH: app/etc/modules/nodwell_Helloworld.xml):


<config>
    <modules>
        <nodwell_Helloworld>
            <active>true</active>
            <codePool>local</codePool>
        </nodwell_Helloworld>
    </modules>
</config>

Now, the module exists, and we can begin to add the code to make it do stuff. We need to configure a route in the config.xml. The route turns a URL into an Action Controller and a method. In our case, it will act on URLs that start with /helloworld, as in http://magento.nodwell.net/helloworld/*. So, add a frontend routers section to the config.xml:


<config>    
    <modules>
        <nodwell_Helloworld>
            <version>1.0.0</version>
        </nodwell_Helloworld>
    </modules>
    <frontend>
        <routers>
            <helloworld>
                <use>standard</use>
                <args>
                    <module>nodwell_Helloworld</module>
                    <frontName>helloworld</frontName>
                </args>
            </helloworld>
        </routers>  
    </frontend>
</config>
 

Now, we create the actual Action Controller (PATH: app/code/local/nodwell/Helloworld/controllers/IndexController.php):

class nodwell_Helloworld_IndexController extends Mage_Core_Controller_Front_Action {        
    public function indexAction() {
        echo 'Hello Index!';
    }
}

Class Naming Conventions and the Autoloader

The way classes are named in Magento was taken from the Zend Framework, upon which Magento was developed.

Class names are standardized depending on their location on the file system. This standardization enables automatic class loading. The Magento autoloader is built in /app/Mage.php. Because class names are directly related to a specific path in the file system, the autoloader allows developers to include them without using include_once or require_once. A class named Mage_Page_Helper_Data, for example, would be found at /app/code/core/Mage/Page/Helper/Data.php

The Main Magento Design Areas

Magento Design Areas
Magento Design Areas
All UI files are contained in three main Magento design areas.

  • /install – files controlling display during installation process
  • /adminhtml – files controlling display of everything you observe while working in the admin panel.
  • /frontend – files controlling display of everything you observe as a customer of the store

Magento Templates and Layout Files

Themes allow you to control the look and feel of your Magento installation and the stores it contains. Related themes are grouped together in design packages, and each store in your installation can use its own theme, share a single theme, or any combination of each. The “base package” is the default design package (a collection of related themes) installed.

The files that determine the visual output and frontend functionality of your store are contained inside the themes in a design package. Each design package must contain a default theme and can contain any number of theme variants.

Themes

theme-design-treeThemes are found in two main directories in the Magento file system:theme-skin-tree

  • app/design – control how the pages are rendered
  • skin – control the visual aspect of the theme (CSS, images, etc)

Theme Files

  • Layout – the basic XML files that define block structure and control meta information
  • Template – contains the PHTML files containing xHTML markups and the PHP for visual presentation (both page and block templates)
  • Locale – CSV documents with language translation strings for non product and category text within Magento

Skin Files

  • CSS – the CSS files for the theme
  • Images
  • JS – the theme-specific JavaScript routines and callable functions

Theme Fall-back

Any files not customized by a particular theme are pulled from the default theme and base package, allowing developers to localize their themes by changing or adding only those files necessary for a custom theme.

  1. If a custom theme is specified, the application looks in:
    1. app/design/frontend/custom_package/custom_theme
    2. skin/frontend/custom_package/custom_theme
  2. If the file is not found in the custom theme, the application looks in
    1. app/design/frontend/custom_package/default
    2. skin/frontent/custom_package/default
  3. If not found in the default, the application looks in
    1. app/design/frontend/base/default
    2. skin/frontend/base/default
  4. If not found, an error occurs

Magento’s Action Controller does not pass a data object to the view or set properties on the view object but rather directly references system models to get the information it needs for display. The view is built by the combination of Blocks and Templates. Blocks are PHP objects, and Templates are PHP/HTML files. Each Block is tied to a single Template file. Inside a phtml file, PHP’s $this keyword contains a reference to the Template’s Block object.

Magento Codepools

codepool

The Magento application contains 3 codepools. Core is reserved for the base classes written by the Core Magento developers. When you want to extend or change the functionality of these classes, you do so by over-riding these classes in your code located in one of the other 2 codepools. Changes to code should never be made in the Core codepool because they may be lost when Magento is upgraded. The Community code pool is where third-party modules, such as the ones downloaded from Magento Connect, can be found. The Local codepool is where any other kind of modification, extension or core (or community) overrides should take place. The Local code pool is loaded first and is the place for changes that need to be made to a specific site or to modify/extend/override what is in the Core or Community codepool.

codepoolconfigDuring the bootstrap, Magento first checks the local codepool for include files, then checks community, and then core. Magento reads a module’s configuration file, looking in the block, to notify the system where to find module code. The module’s configuration file is located in /app/etc/modules.
codepoolconfigfileloc

/app/Mage.php defines the pathing for the three code pools.