MAGENTO’S THEME FALLBACK MODEL
Magento’s theme architecture was changed between Community Edition (CE) v1.3 and CE v1.4 and between Enterprise Edition (EE) v1.7 and EE v1.8 to make custom themes easier to maintain and more “upgrade proof.” In these releases the theme files were also refactored and changed considerably to improve performance and accessibility, but the biggest change was to the overall theme structure and hierarchy used by Magento.
Magento has always used fallback logic in rendering themes, but with CE v1.4 and EE v1.8, this has been expanded to include the base package as the final cross-package fallback point. In previous Magento versions, fallback was only inside of a theme and customized frontend functionality could not be shared between packages without replicating all of the files to each package.
An example of how Magento’s fallback logic works is, if your custom theme calls for a CSS file named ”styles.css,” but the Magento application is unable to find the file in your custom theme, Magento will search the next theme in the hierarchy for the file and continue searching the hierarchy of themes until it locates the file named ”styles.css.“ This method of building design is called “fallback” because the application ”falls back” to the next possible source of required files in order to retrieve and load a requested file.
Fallback e.g style.css look for package/theme ->if notfound -> package/default->if notfound ->base/default->display error
When used effectively, this fallback mechanism allows you to edit and maintain only the files you need to change as a custom theme and all of the other functionality is provided by either the custom package default theme or the base package.
For example, Magento maintains 4 CE demo themes—default, blank, modern, and iPhone. Before the introduction of the base package, all theme files had to be copied to each package and maintained, tested and debugged in each. With the introduction of the base package, we maintain three times less code. For example, the default/default and default/blank themes are implemented with just CSS changes and get all template and layout files from the base package.
---------------------------------------------------------------------------------------
Magento’s theme architecture was changed between Community Edition (CE) v1.3 and CE v1.4 and between Enterprise Edition (EE) v1.7 and EE v1.8 to make custom themes easier to maintain and more “upgrade proof.” In these releases the theme files were also refactored and changed considerably to improve performance and accessibility, but the biggest change was to the overall theme structure and hierarchy used by Magento.
Magento has always used fallback logic in rendering themes, but with CE v1.4 and EE v1.8, this has been expanded to include the base package as the final cross-package fallback point. In previous Magento versions, fallback was only inside of a theme and customized frontend functionality could not be shared between packages without replicating all of the files to each package.
An example of how Magento’s fallback logic works is, if your custom theme calls for a CSS file named ”styles.css,” but the Magento application is unable to find the file in your custom theme, Magento will search the next theme in the hierarchy for the file and continue searching the hierarchy of themes until it locates the file named ”styles.css.“ This method of building design is called “fallback” because the application ”falls back” to the next possible source of required files in order to retrieve and load a requested file.
Fallback e.g style.css look for package/theme ->if notfound -> package/default->if notfound ->base/default->display error
When used effectively, this fallback mechanism allows you to edit and maintain only the files you need to change as a custom theme and all of the other functionality is provided by either the custom package default theme or the base package.
For example, Magento maintains 4 CE demo themes—default, blank, modern, and iPhone. Before the introduction of the base package, all theme files had to be copied to each package and maintained, tested and debugged in each. With the introduction of the base package, we maintain three times less code. For example, the default/default and default/blank themes are implemented with just CSS changes and get all template and layout files from the base package.
---------------------------------------------------------------------------------------
No comments:
Post a Comment