Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Magento 2.0: Prepare yourself for a new way of module development


Published on

Published in: Technology

Magento 2.0: Prepare yourself for a new way of module development

  1. 1. Join us in Ibiza September 24th – 27th 2012
  2. 2. Magento 2.0:Prepare yourself for a new way of module development Ivan Chepurnyi
  3. 3. About Me • Devoted to Magento Platform, since May 2007 • Former Magento Core Team member • More than 5 Years of Magento Development Experience • Technical Director at EcomDev • Magento Coach for European developers
  4. 4. Magento 1.x Issues
  5. 5. Non-transparent Module Structure app/design app/code Layout PHP Classes Templates Configuration Module Functionality Emails Definition Translations Static Data app/locale app/etc/modules skin
  6. 6. Excessive Configurations • Info for building classes names of • Models • Blocks • Helpers • Info about file path • Layout • Translate
  7. 7. Performance • Timings for app initialization • Excessive memory usage for building of page layout • Loading of redundant XML configurations for each request
  8. 8. Magento 2.0 Module Changes
  9. 9. Module Structure in Magento 2.0 app/code/<codePool>/<Namespace>/<Module> Model Helper Classes that are used in MVC application Block controllers Configuration files etc Setup Scripts sql data Layouts, Templates, Static Data view Translations locale
  10. 10. Refactored Configuration
  11. 11. Changes in Main Configuration • Definition of the module in app/etc/modules/<Module_Name>.xml moved to its etc/config.xml file • Added option to specify dependency type • Removed class aliases • Fieldsets copy rules moved to a separate file • Simplified rewrite system
  12. 12. New Modules Bootstrap Logic 1. Merging only <modules /> nodes from the following file paths: 1. app/code/pool/Mage/<Module>/etc/config.xml 2. app/code/pool/<Namespace>/<Module>/etc/config.xml 3. app/etc/modules/<Namespace_ModuleName>.xml
  13. 13. New Modules Bootstrap Logic 2. Sorting of modules by dependency and checking module activity 3. Merging of the config.xml file from sorted and active modules
  14. 14. Dependency Types • Hard Dependency (By Default) • Soft Dependency Snippet: <Namespace_Module> <depends> <Mage_Category type=“soft”/> <Mage_Core /> <!– This one is hard dependency  </depends> </Namespace_Module>
  15. 15. No More Class Aliases • A full class name specified in all factory calls • Mage::getModel(‘Namespace_Module_Model_Name’); • Mage::helper(‘Namespace_Module_Helper_Name’); • etc… • Now all the factories use the same service locator
  16. 16. Rewrite Is Simplified Rewrite is specified for class name instead of <models />, <helpers /> and <blocks /> nodes: <global> <rewrites> <ClassName_To_Rewrite>Class_That_Sustitutes</ClassName_To_Rewrite> </rewrites> </global>
  17. 17. Configuration Changes In Admin Panel 1. New ACL and authorization system • Acl resources now placed at <Module>/etc/adminhtml/acl.xml • It is even possible to connect own authentication model 2. Introduced Menu Builder • A separate xml file at <Module>/etc/adminhtml/menu.xml • Menu is build by XML instructions: <add />, <update /> and <remove /> 3. Added schema for these XML files validation
  18. 18. View Layer Changes
  19. 19. View Structure in Module • Layout, templates, module CSS and JS files moved from <area>/base/default theme and skin to the module directory • There is no more template and layout directories on view level • Module has a view configuration file for defining own variables
  20. 20. View Directory Magento Application Area view (frontend, adminhtml, install) <area> Layout File that is defined in module config.xml layout.xml Template that is specified via template.phtml layout or block construct css/file.css Static files that can be file.js included into HTML markup via layout or template image.jpg
  21. 21. View Configuration • File is merged from all modules and current theme: • <Module>/etc/view.xml • <theme>/view.xml • It has XML scheme for the validation of its content • Can be used in feature for Design Editor
  22. 22. View Configuration Example In module config or theme: <?xml version=“1.0”?> <view> <vars module=”Namespace_Module”> <var name=“items_count”>10</var> </vars> </view> In template or block: $this->getVar(‘items_count’, ‘Namespace_Module’);
  23. 23. Changes in Layout • Changes in layout building behavior • Hierarchical Layout Handles • Containers instead of structural blocks • New <move /> layout element
  24. 24. Layout building behavior 1. Adding layout handles updates 2. Extracting current handles and processing <update handle=“<name>”/> node 3. Transforming XML structure into array tree and sorting blocks within that tree without creating the block 4. Applying scheduled remove and move operations 5. Building blocks and containers from array tree
  25. 25. Hierarchical Page Handles • Realized via attributes for layout handle: • type=“page” • parent=“handle_name” • Helps getting rid of layout duplicates • Used to specify which layout handles are pages in Design Editor functionality
  26. 26. Example of Page Handle <catalog_category_view translate="label” type="page” parent="default”> <!– some structure --> <catalog_category_view> <catalog_category_view_type_layered translate="label” type="page" parent="catalog_category_view”> <!– some structure --> <catalog_category_view_type_layered>
  27. 27. No more structural blocks • Blocks will be refactored to be a final unit of view • Containers will replace structural blocks • Containers are not objects, they are rendered and managed by layout model
  28. 28. Container Element <container name=“unique_name” Same as for block as=“alias_in_parent” ≈ Container HTML properties before=“sibling_name” (optional) after=“sibling_name” htmlTag=“div” htmlClass=“css-class” ≈ htmlId=“id-in-html” label=“Container Name in Design Editor”> <container /> <block /> Container Name for Design Editor </container> functionality
  29. 29. Move Statement The element that should be moved <move element=“name” Destination element in layout destination=“destination.element” as=“new_alias” Same as for block after=”sibling_name” ≈ before="sibling_name” />
  30. 30. Themes
  31. 31. Simplified Themes • Themes become more simple and flexible • Only one configuration field in the admin panel • It is possible to create as many inherited themes as you need • Skin become a style/locale variation on theme level • Strict files relation in theme to the module
  32. 32. Theme Definition • Every theme is defined by theme.xml in its directory • app/design/<area>/<package>/<theme>/theme.xml • It contains: • Requirements for Magento version • Fallback information • Name of the theme for admin user
  33. 33. Theme Definition <design> <package code=”package_code”> <title>Default</title> <theme version="" code=”theme_code” parent=“theme_code”> <title>Default</title> <requirements> <magento_version from=”” to=“|*"/> </requirements> </theme> </package> </design>
  34. 34. Theme Definition • package/title – package name, that is visible to admin user • theme/title – theme name, that is visible to admin user • package/@code – unique identifier of a package • theme/@code – unique identifier of a theme within the package
  35. 35. Theme Definition • theme/@version – internal version of theme • theme/@parent – theme name that the current one is inherited • magento_version/@from – minimal required Magento version for theme • magento_version/@to - maximum compatible version of Magento for theme (can be a wildcard)
  36. 36. Theme Fallbacks Fallback structure for dynamic files looks quite simple, but you should consider theme inheritance: 1. <theme>/<Namespace_Module>/layout.xml 2. <parent_theme>/<Namespace_Module>/layout.x ml 3. <Module>/view/layout.xml
  37. 37. Skin Fallbacks • Static files (JS, CSS, Images) should be placed in theme skin directory • Theme can have multiple skins, the default skin is “default” • Skin directory allows fallbacks on locale level • <theme>/skin/<skin_code>/<locale_code>/file.js • <theme>/skin/<skin_code>/file.js • <theme>/skin/<skin_code>/<locale_code>/<Namespace_Module>/file.js • <theme>/skin/<skin_code>/<Namespace_Module>/file.js
  38. 38. Localization Inheritance
  39. 39. Localization Inheritance It is possible to define inheritance between locales in any xml file that is merged for global configuration: <global> <locale> <inheritance> <!-- Inheritance of UK Locale from US one --> <en_GB>en_US</en_GB> </inheritance> </locale> </global>
  40. 40. Developer Stuff
  41. 41. Developer Stuff • dev/shell – same as Magento 1 shell directory • dev/tests – set of different test suites: • integration – tests that require Magento initialization • js – Java Script UnitTests • unit – test that can be run without Magento • performance – load tests • static – code analysis tools
  42. 42. Developer Stuff • dev/tools – tools for developer • migration – a set of tools for migration of Magento 1.x module to 2.0 • classmap – generator of the class map • batch_tests – batch test runner
  43. 43. Thank You
  44. 44. Your Questions E-mail: