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.

Applying Code Customizations to Magento 2

354 views

Published on

Code Customization and Extension techniques for Magento 2

Published in: Software
  • Be the first to comment

Applying Code Customizations to Magento 2

  1. 1. Applying Code Customizations to Magento 2
  2. 2. Who am I? Igor Miniailo
  3. 3. Interactions with Magento2 Code
  4. 4. Extension UI Model UI Model Service Contracts Service Contracts Vendor
  5. 5. Customization UI Model Model Service Contracts Vendor
  6. 6. Customization Points
  7. 7. Customization points Admin Configuration Low Level Linking High-level configuration (DSLs) events.xml routes.xml routes.xml webapi.xml acl.xml di.xml Object B Object C Object A Object B config.xml
  8. 8. Store Configuration
  9. 9. Store Configuration • In admin application: Stores->Configuration • Values stored in Database • Configured in system.xml • Default values in config.xml
  10. 10. High Level Configuration
  11. 11. Routing High-level Configuration Event Manager events.xml routes.xml
  12. 12. Application subsystems AreaApplication EntryPoint Cron App Web App WebAPI Admin FrontendMedia App
  13. 13. Low Level linking
  14. 14. 1. Composability 2. Modularity
  15. 15. Composability
  16. 16. Composability Split your code to lots of small chunks and then compose them to build your application
  17. 17. Dependency Injection Dependencies are not located within object but are provided to that object by environment namespace MagentoFrameworkEvent; class Manager implements ManagerInterface { public function __construct( Invoker $invoker, Config $eventConfig, $prefix = '' ) { $this->_invoker = $invoker; $this->_eventConfig = $eventConfig; $this->_prefix = $prefix; } // some other code }
  18. 18. Unit Tests class ManagerTest extends PHPUnit_Framework_TestCase { protected function setUp() { $this->_invoker = $this->getMock('MagentoFrameworkEventInvoker'); $this->_eventConfigMock = $this->getMock('MagentoFrameworkEventConfig'); $this->_eventManager = new MagentoFrameworkEventManager( $this->_invoker, $this->_eventConfigMock ); } }
  19. 19. SOLID 1. Single responsibility – Lots of small objects 2. Open Closed - Each object has multiple extension points 3. Liskov Substitution – Polymorphism for composability 4. Interface Segregation – Granularity 5. Dependency Inversion – Decoupling. In particular, any caller of an interface depends only on the interface, even if a separate module implements it.
  20. 20. Modularity
  21. 21. SOLId Module B Module A Implementation Module B Module A Implementation Interface Module C Implementation Module AB Module AC Impl Impl Coupled Decoupled
  22. 22. Modules Definition Modules serve as named containers for domain object classes that are highly cohesive with one another. The goal should be low coupling between the classes that are in different Modules
  23. 23. Simple rules for Module design • Ensuring that Modules are largely independent of others has the same benefit as loosely coupled classes. This will make it easier to maintain and refactor code inside the module. • Do strive for acyclic dependencies on Modules where coupling is necessary. Just unidirection
  24. 24. Service Contracts And Compatible Customizations
  25. 25. Extensions Compatibility Challenges  Interfaces may be changed in a new version  Extensions may depend on optional modules which is turned off  Extensions may depend on undocumented behavior How to ensure that two extensions will be compatible in a new version?
  26. 26. Challenges for Developer How to understand what functionality of the extension is stable and what is not? How to implement extension in the way that it will keep backward compatibility but can evolve?
  27. 27. Stable APIs  Backward Compatible:  Classes or Interfaces are not removed  Methods of the classes keeps signature between versions  Interfaces neither changes existing methods nor add new ones  Explicit Interfaces  No generic data types as “mixed”, “object” or “array”
  28. 28. Few ways to make promises in Magento 2 Semantic Versioning of the modules makes dependencies between modules explicit { "name": "magento/module-catalog-inventory", "require": { "magento/module-customer": "0.74.0-beta2" }, "type": "magento2-module" } /** * @api */ interface AuthorizationInterface { /** * Check current user permission on resource and privilege * * @param string $resource * @param string $privilege * @return boolean */ public function isAllowed($resource, $privilege = null); } @api annotation identifies subset of the methods with the stable APIs Enforced by tools and static tests
  29. 29. http://alankent.me/2015/10/02/magento-2- version-numbering-update/ MAGENTO 2 VERSION NUMBERING
  30. 30. Magento 1.x Domain Level API  Model is an entry point to the Module  Interface implicitly defined via the database schema  No single place for the business rules They can be in:  Controllers  Models  Helpers  Templates Model Resource Model Client getData()
  31. 31. Repositories Service Contracts Models Resource Models/Entity Manager Web API clients M2 Module Blocks TemplatesControllers Other M2 Modules Services Data Objects Service Contracts
  32. 32. Domain Level API Single way to define API for the business feature  Defines strong interface  Single place to implement business rules  All interactions with the module are safe to go through the contracts: same behavior guaranteed Repositories Service Contracts Models Resource Models/Entity Manager M2 Module Blocks TemplatesControllers Services Data Objects
  33. 33. Service Contracts Interfaces Service Contracts Service Interfaces Data Interface Data interfaces  Defines data structures, used as input and output types of the business operations  Examples: Customer, Product, Region, Currency, etc. Service interfaces  Defines business operations  Examples: load, delete, save, change password, etc. They are just PHP Interfaces
  34. 34. More on Data Interfaces  Has just setters and getters to describe a data  Reusable across different Service interfaces  Encapsulates all the data needed to process service request  Can be Serialized  Annotations are used to extract the data
  35. 35. More on Service Interfaces  Defines public operations supported by the module  Methods are independent and stateless.  Invocation of one method should not affect the result of another  Methods combined in interface by cohesion principle  Annotated with types information
  36. 36. Classes Implementing Data Interfaces  It can be Model (NOT Recommended):  All the setters and getters should be declared explicitly  No magic methods  It can be Any PHP class:  Implements data interface and any other methods  It can be Data Object:  Implements just methods from the data interface Models Data Objects Data Interfaces
  37. 37. Implementation of Service Interfaces  Resource Models (legacy, not recommended):  Used for persistence operations  Implements load/save/delete methods and accept Data Interface as an input  Entity Manager:  Used for persistence operations  ORM implementation  Services:  Implements operations and business rules around them Service Interfaces Resource Models/EntityM anager Services
  38. 38. Use Service Contracts  Define dependency on service interface in the constructor class CreateCustomer extends MagentoCustomerControllerAccount { public function __construct( AccountManagementInterface $accountManagement ) { $this->accountManagement = $accountManagement; } public function execute() { $customer = $this->getRequest()->getParam('customer'); $password = $this->getRequest()->getParam('password'); $redirectUrl = $this->getRequest()->getParam('redirect_url'); $customer = $this->accountManagement ->createAccount($customer, $password, $redirectUrl); … } }
  39. 39. Re-Implement Service Contracts  Define a preference in DI: it will point on a new implementation  All the constructors will be injected with a new implementation <preference for="MagentoCustomerApiAccountManagementInterface" type="SomeVendorNewExtensionModelAccountManagement" /> <preference for="MagentoCustomerApiDataRegionInterface" type="SomeVendorNewExtensionModelDataRegion" />
  40. 40. Customize Service Contracts  Plugins is a way to add new behavior each time Service Interface implementation is invoked /** * Plugin after create customer that updates any newsletter subscription that may have existed. * * @param CustomerRepositoryInterface $subject * @param CustomerInterface $customer * @return CustomerInterface */ public function afterSave(CustomerRepositoryInterface $subject, CustomerInterface $customer) { $this->subscriberFactory->create()->updateSubscription($customer->getId()); return $customer; }
  41. 41. Extend Data Interfaces  Extension Attributes is a way to Extend Data Interfaces from third- party module  Added via xml configuration, generated as an object Review fields Catalog Inventory fields Rating and Reviews Module Catalog Inventory Module Product Data Interface Product fields
  42. 42. Generated Extension Attributes <extension_attributes for="MagentoCatalogApiDataProductInterface"> <attribute code="bundle_product_options" type="MagentoBundleApiDataOptionInterface[]" /> </extension_attributes> interface ProductExtensionInterface extends MagentoFrameworkApiExtensionAttributesInterface { /** * @return MagentoBundleApiDataOptionInterface[] */ public function getBundleProductOptions(); /** * @param MagentoBundleApiDataOptionInterface[] $bundleProductOptions * @return $this */ public function setBundleProductOptions($bundleProductOptions); ... }
  43. 43. Summary  Magento 2.x gives stronger promises on public APIs  Service Contracts are the way to define API for the Business features  Service Contracts should be the single entry point to functionality of the module  Customizable via dependency injection, plugins and extension attributes  Customizations become available for all the clients of Service Contracts
  44. 44. Thank you! Igor Miniailo iminiailo@magento.com Q & A

×