Magento Structure Analysis

Magento Module

Module is the core of Magento. Any action on the site, either in the foreground or in the background, is implemented through a module. A module can be treated as a container that can contain the following items: Set (settings), database schema, render object (rendering object), Auxiliary tool Class (utility helpers), data models) or action controller (action controllers). A module can contain all of these six items and can contain only a few of them, or even one. All modules can be switched via the XML configuration system in the app/etc/modules/directory. Each module can also create an XML file in the ETC subdirectory of its own module directory to hold its own configuration information.

Since everything in Magento is a module and the module itself can have its own configuration files and database settings, it allows developers to extend the Magento.

Module structure

The following is the directory structure of the catalog module, which contains all the items of the module (the six items mentioned above):

Code Pool (pools)

All modules in the Magento are placed in three code pools, which are core, local, community, respectively. The modules that accompany the Magento itself are all placed in the core code pool. The modules you develop yourself are installed in the local code pool. As for the Community Code pool, it is used to install third-party modules, but the idea is also likely to be outdated, because the modules can be installed in the Lcoal code pool or installed in the Community code pool, rather than having to be broken down.

Packages (Package)

All modules are not stored directly in the code pool directory, but are stored in the package directory (the subdirectory of the Code pool). The main purpose of the introduction package concept is the unity and consistency of class naming. All Magento modules are stored in the Mage package in the core code pool. Therefore, all Magento class names are prefixed with Mage_. And for our own development of code we should create a package in the Lcoal code pool, such as the name of your company as the package name, so you can avoid the possibility of duplication of class names.

Models (model)

The model can be said to be Magento muscle. It is mainly used to extract data from the database into the program. The output of the data is implemented through blocks. In other words, it is mainly used for database operations. In fact, in any programming environment, the model is used to identify the work of processing data fields, which means that it plays a role in the definition of data sets and other related data groups.

To illustrate the previous modelling theory, let's give an example: when creating a shopping cart system, we have a Product class. Each product requires one to specify a picture. The question is how is the image modeled? Simply give the Product Class A $image _url property? or create a Image_gallery class, and then create an interface between the two classes, such as GetDefaultImage. The final model class depends on how you decide to implement the operation between the data.

Blocks (block)

Block is the brain behind the Magento template pattern. All blocks form a set of nested object set coordination models and template files. Each block corresponds to a template file-the template file is a file that mixes HTML and PHP code with a. phtml extension. In other words, for any request on Magento, you are dealing with a series of block objects and the corresponding number of template files.

The Magento template system is the PHP language itself. It does not re-implement a templating system, so the Renderview () method is simply a simple call to include to contain the associated template file. In other words, if you want to use a template engine instead of a simple PHP language, you can invoke the rendering function of the template system you selected by modifying the Renderview method of the Mage_core_block_template class.

Controllers (Controller)

The controller is the starting point for all Magento business logic. Business logic refers to the rules in business theory. As for

The distinction between Magento business logic and domain logic (data processing instructions) is less obvious. Some people think that checking the required fields and optional fields belongs to the business logic, while others think that should belong to the domain logic. Most of the logic in Magento is implemented in the model.

The controller class inherits the Mage_core_controller_varien_action base class, which is a modified version of the Zend_controller_action class of the Zend framework. Some of the more important methods include:

L Dispatch ($action)

L Predispatch ();

L Postdispatch ()

The other way is simply to use the URL to pass instructions to other critical parts of the system. The Dispatch () method starts all the business logic for the current request, and the value $action is determined by the URL, which is usually index. The Dispatch method first calls the Predispatch method, which triggers the following events, and you can listen to these events and add the processing code:

N Controller_action_predispatch

N Controller_action_predispatch_modulename

N Controller_action_predispatch_modulename_controllername_actionname

The dispatch method is called only at the end of the Predispatch method when the current request is marked as dispatched, and eventually it invokes the corresponding action method in the corresponding controller instance, see:

Helper classes (Helpers)

The auxiliary classes in Magento are the means to extract those auxiliary interfaces from the kernel classes. We usually have both the block class and the interface that calls the helper class in the model class, so the return value of these interfaces is unreliable, and you will almost never inherit an auxiliary class, because you can add a new secondary interface directly by adding a helper class.

But you will be interested in the two important interfaces of the auxiliary classes are:

L __ (two underline)

L Htmlescape

The double underline method is the translation interface. It is almost encapsulated by all objects, meaning you can call this method almost anywhere in the code to translate a string. Htmlescape simply encapsulates the Htmlspecialchars function, but it can also receive an array and apply the Htmlspecialchars function to each element in the group.

configuration file (config files)

The configuration file for the module is stored in the ETC subdirectory of the module directory. Each module can have three configuration files, all of which are XML files. where CONFIG. System.Xml directly affects the behavior of your module, the other two files will automatically create a setup form for you in the Background configuration page (Convert.xml).

The configuration files for all modules are eventually grouped together. This means that you can set the configuration in the corresponding XML tag of a module to override or overwrite the corresponding configuration of any module, which is the essence of Magento rewriting.

For some reason, you can create a class, create a config. file, and specify your class name in the same location, so you can install your class into the system.

This is also why you see a call that resembles Getmodel (' catalog/product ') everywhere in the system, rather than simply a call like this: New Catalog_model_product ();.

Each class-to-label, name-use gives you a powerful way to rewrite any part of the system.

Note: The upper and lower files that are assumed in the class name using tags may be Block, Model, Helper.

Template system

The template system in Magento is very controversial. Some users have an opinion about using PHP as a templating system. But using PHP as a templating system is not as simple or as powerful as a template system, at least in the long run. In my opinion, this is the most flexible and most advanced template system.

A complete page is implemented by a set of nested template files (which should theoretically be a set of nested block objects). There is no concept of "component" in the system, meaning you will not have a "Form", "button" class or object. Template files and block objects are controlled through a set of XML files, which helps developers develop plug-ins, but it seems to be a bit difficult for designers, even those who are familiar with PHP.

Layout file

The layout file controls the final structure of the page. All layout files are saved in the current theme's layout directory. All layout files have the same name as the corresponding module name, except that they all use lowercase, and the module name uses the so-called camel-like nomenclature. One of the most important layout files is the Page.xml file

The Page.xml file specifies the default page structure. Modifications from other XML files are from the settings under the default tag. The following are commonly used tags in layout files:

L Layout

L Default

L Reference

L Block

L Action

L Update

You may also see tags like the following, which are handle by layout in Magento, and they work the same as the default tag, but only for certain requests. These tags follow a pattern, which is associated with the module name, controller name, and action name. If a label has only two parts and the underscore is separate, such as Cms_page, then all the settings under this tab will be applied to all requests under the corresponding controller under the module.

Template file

There is not much introduction to template files, they are simply files that nest PHP code in HTML files, with. phtml as the extension. The template features of PHP syntax are used in these files, and you'll see another PHP loop structure that uses colons, as well as endwhile,endfor,endif.

The directory structure of the template file mimics the directory structure of the corresponding module, but this is not required. I found that when developing my own modules, it would be much easier to name template files and save them in a directory without the Magento habit. You can replace the slash in the file name with an underscore, which is equivalent to copying the file name of your module. If you need to rewrite a set of files, no matter where the file, whether it is a few files, to see exactly what files are rewritten, it is best to rewrite them and save them in a directory.

There are some important template files you need to be familiar with, that is, template files in the page directory. All template files in this directory have the highest level when modifying your page. These files specify which pages have 1, 2, or 3 columns, and also provide pages similar to dashboard and print layouts.

Although you can add the highest level template file to the page directory of your own theme, only the template file under the page directory in the default theme in the default interface can be selected through the background management interface. For example, you want a page structure with four columns, so you create a 4-column.phtml, but you can't choose this template file from the Admin interface. However, you can re-define the page structure as 4-column.phtml in the layout file (override). So this is just a limitation on the user interface.

Original: http://yonglailizhi.iteye.com/blog/792775

Magento Structure Analysis