Questions tagged «dependency-injection»

表示有关Magento 2依赖注入的问题

3
type和virtualType有什么区别
在di.xmlMagento2随附的中，有一个节点type和一个节点virtualType。我的问题是这是virtualType什么type？在什么情况下应使用它代替？ 在某些地方，它看起来像是符号链接或重写： <virtualType name="Magento\Core\Model\Session\Storage" type="Magento\Framework\Session\Storage"> 一个完整的路径被更改为另一个完整的路径，而在其他地方，它似乎被用作定义较短别名的一种方式。 <virtualType name="lessFileSourceBase" type="Magento\Framework\View\File\Collector\Base">
3
是什么触发了Magento 2中工厂的产生
Magento 2包含许多预先生成或即时生成的类文件。他们住在 var/generated 这些生成的文件包括工厂类。根据文档，据我了解，程序员使用工厂类来实例化“不可注入”对象。“不可注入”对象是无法通过__constructor依赖项注入添加的对象，通常是因为它需要用户输入才能实例化。 从文档中不清楚的是Magento 2如何知道它需要生成工厂类。这一点 如果对象管理器在运行时模式或编译器中遇到不存在的工厂，则对象管理器将生成工厂。 听起来好像我在对象管理器中使用工厂类（或者，在依赖项注入__constructors中使用扩展）时，Magento 2会为我生成它。但是对象管理器如何知道我要的东西是工厂？ 同样，似乎有两个 命令可以自动生成（或“编译”）所有生成的类。运行这些命令中的任何一个都会生成大量的Factory类。 这些命令在寻找什么配置和/或代码文件以生成所需的工厂对象？ 我知道一直追踪对象管理器和/或命令代码将揭示这一点，但是我希望避免那漫长而艰巨的旅程。
5
实例化助手在Magento 2
Magento 2的最新版本已经消除了Mage该类。这意味着我们已经丢失了该Mage::helper方法。 在Magento 2中是否存在用于实例化助手的替代技术（助手工厂？）？还是我们应该使用新的对象管理器类，并使用get（vs. create）将帮助程序实例化为单例/缓存对象。
2
Magento 2：$ data数组构造函数参数是什么？
因此，我注意到在大多数模型和块中，这array $data = []是构造函数的最后一个参数。 例如 \Magento\Catalog\Block\Product\ListProduct public function __construct( \Magento\Catalog\Block\Product\Context $context, \Magento\Framework\Data\Helper\PostHelper $postDataHelper, \Magento\Catalog\Model\Layer\Resolver $layerResolver, CategoryRepositoryInterface $categoryRepository, \Magento\Framework\Url\Helper\Data $urlHelper, array $data = [] ) { $this->_catalogLayer = $layerResolver->get(); $this->_postDataHelper = $postDataHelper; $this->categoryRepository = $categoryRepository; $this->urlHelper = $urlHelper; parent::__construct( $context, $data ); } 我还知道，在处理首选项时，当添加的参数比原始构造函数更多时，仍必须将该参数保留在构造函数参数列表的末尾。 所以我对这个数组有几个问题： 它是什么 ？ 如何使用它 ？ 声明添加更多参数的块的首选项时，为什么需要将其保留在构造函数参数列表的末尾？
2
Magento 2 DI最佳做法
假设我正在构建一个Magento 2扩展程序，它确实......不重要。假设它的确很棒。 但是我想确保它是使用正确的标准构建的，以便其他开发人员可以对其进行扩展。 什么时候应该将DI与接口结合使用，什么时候不应该？ 这里要说明的是一个核心示例。 该类Magento\Core\Helper\Data具有如下构造函数： public function __construct( \Magento\Framework\App\Helper\Context $context, \Magento\Framework\App\Config\ScopeConfigInterface $scopeConfig, \Magento\Store\Model\StoreManagerInterface $storeManager, \Magento\Framework\App\State $appState, PriceCurrencyInterface $priceCurrency, $dbCompatibleMode = true ) { parent::__construct($context); $this->_scopeConfig = $scopeConfig; $this->_storeManager = $storeManager; $this->_appState = $appState; $this->_dbCompatibleMode = $dbCompatibleMode; $this->_priceCurrency = $priceCurrency; } 我的问题集中在var上\Magento\Framework\App\Config\ScopeConfigInterface $scopeConfig（我知道同一构造函数中还有其他变量，但是一种解释适合我认为的所有情况）。 根据di.xml核心模块中的，var将是以下实例Magento\Framework\App\Config： <preference for="Magento\Framework\App\Config\ScopeConfigInterface" type="Magento\Framework\App\Config" /> 但是我可以根据需要轻松更改它。 什么时候应该在代码中使用类似的接口？ …
4
Magento 2：什么是代理类的实际解释？
因此，我从理论上知道Magento 2中的代理类是什么。我已经阅读了有关Alan Storm的精彩文章，并且我完全理解了这些类是如何生成的。 但是，我不知道这是因为我不是英语母语人士，还是Alan的解释是否使用了非常抽象的非核心类，但是我很难理解它的工作原理，特别是何时使用在开发过程中。 因此，让我们以以下示例为核心app/code/Magento/GoogleAdwords/etc/di.xml： <?xml version="1.0"?> <!-- /** * Copyright © 2016 Magento. All rights reserved. * See COPYING.txt for license details. */ --> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd"> <type name="Magento\GoogleAdwords\Observer\SetConversionValueObserver"> <arguments> <argument name="collection" xsi:type="object">Magento\Sales\Model\ResourceModel\Order\Collection\Proxy</argument> </arguments> </type> </config> 我想知道： 为什么在这种特定情况下使用代理类？ 通常，什么时候应该使用代理类？
3
在Magento 2中为Abstract类添加新方法
就像这个线程所说的那样：在Magento 1中覆盖Magento 2中的抽象类， 我可以创建一个全新的类。在Magento 2中，我们需要使用插件，但是插件仅允许我修改现有方法。如果我想添加新方法该怎么办？ 例： 此类vendor/magento/module-ui/Component/AbstractComponent.php具有一个数组数组：$components，没有用于取消/删除该数组元素的函数。那么如何创建该功能呢？
1
DI和Magento 2上的扩展块
每当我尝试扩展不是\ Magento \ Framework \ View \ Element \ Template的块时，我似乎都难以理解带有块的Magento 2依赖项注入，但最终会出错。 我想创建一个扩展Magento \ Theme \ Block \ Html \ Header \ Logo的非常基本的块类的块 -一切正常，直到我尝试在construct方法中进行依赖注入： <?php namespace Creare\Test\Block\Header; class Logo extends \Magento\Theme\Block\Html\Header\Logo { protected $_creareHelper; public function __construct( \Magento\Framework\View\Element\Template\Context $context, \Creare\Seo\Helper\Data $creareHelper, array $data = [] ) { $this->_creareHelper = $creareHelper; parent::__construct($context, …
2
Magento 2：使用语句还是直接类路径？
我可能遗漏了一点，但我只是想知道为什么有时对于特定的类有一个“使用”语句，而有时却没有。 示例：app\code\Magento\Email\Model\Template.php，我们位于文件顶部： namespace Magento\Email\Model; use Magento\Store\Model\ScopeInterface; use Magento\Store\Model\StoreManagerInterface; 然后，在该__construct方法中，我们具有以下参数： public function __construct( \Magento\Framework\Model\Context $context, \Magento\Framework\View\DesignInterface $design, \Magento\Framework\Registry $registry, \Magento\Store\Model\App\Emulation $appEmulation, StoreManagerInterface $storeManager, \Magento\Framework\View\Asset\Repository $assetRepo, \Magento\Framework\Filesystem $filesystem, \Magento\Framework\App\Config\ScopeConfigInterface $scopeConfig, \Magento\Email\Model\Template\Config $emailConfig, \Magento\Email\Model\TemplateFactory $templateFactory, \Magento\Framework\Filter\FilterManager $filterManager, \Magento\Framework\UrlInterface $urlModel, \Magento\Email\Model\Template\FilterFactory $filterFactory, array $data = [] ) 因此，我们可以清楚地看到，正如我们use Magento\Store\Model\StoreManagerInterface;在类顶部调用的那样，我们能够StoreManagerInterface $storeManager在构造函数参数中进行操作。 我的问题是： 为什么我们只为一个班级这样做？ 为什么我们不能use为构造函数的每个类添加一条语句，以便不必键入完整的类路径？ 或反过来，为什么我们不删除该use语句并键入StoreManagerInterfaceclass …
3
如何在Magento 2中覆盖Virtual Type类
如何在Magento 2中覆盖VirtualType块，我想用自己的块覆盖以下虚拟类型块， <virtualType name="Magento\CatalogSearch\Block\SearchResult\ListProduct" type="Magento\Catalog\Block\Product\ListProduct"> <arguments> <argument name="catalogLayer" xsi:type="object">Magento\Catalog\Model\Layer\Search</argument> </arguments> </virtualType> 所以我试图di.xml像这样从我的自定义模块中覆盖它， <preference for="Magento\Catalog\Block\Product\ListProduct" type="My\Vendor\Block\Product\ListProductSearch" /> 但这行不通。 那么，在Magento 2中重写虚拟类型类的正确方法是什么？
5
为什么我不能在Magento 2中注入ProductRepositoryInterface？
我有一个控制器动作，我想将产品存储库注入其中 namespace Nosto\Tagging\Controller\Export; use Magento\Catalog\Api\ProductRepositoryInterface; use Magento\Store\Model\StoreManagerInterface; use Magento\Backend\App\Action; use Magento\Framework\App\Action\Context; class Test extends Action { private $_productRepository; public function __construct( Context $context, StoreManagerInterface $storeManager, ProductRepositoryInterface $productRepository ) { parent::__construct($context); $this->_storeManager = $storeManager; $this->_productRepository = $productRepository; } 无论我以什么顺序放置构造函数参数，Magento的依赖项注入总是为该productRepository参数注入一个无效的类，从而导致PHP抛出和参数错误。该storeManagerGETD注射就好了。清除缓存没有帮助。 这是引发的异常： Recoverable Error: Argument 3 passed to Nosto\Tagging\Controller\Export\Test::__construct() must implement interface Magento\Catalog\Api\ProductRepositoryInterface, …
3
将依赖项注入Magento 2 CRUD /抽象模型
是否可以将依赖项注入到Magento 2 CRUD模型中？ 也就是说-Magento 2有一个基本的抽象模型类：Magento\Framework\Model\AbstractModel。如果要创建简单的“创建，读取，更新，删除”模型对象，则可以使用自己的类来扩展该类。 class Foo extends Magento\Framework\Model\AbstractModel { } 是否可以在模型的__construct方法中注入依赖项？当我尝试时，最终出现以下错误。 致命错误：无法实例化抽象类Magento \ Framework \ Model \ ResourceModel \ AbstractResource 罪魁祸首似乎是AbstractModel的__construct方法。 public function __construct( \Magento\Framework\Model\Context $context, \Magento\Framework\Registry $registry, \Magento\Framework\Model\ResourceModel\AbstractResource $resource = null, \Magento\Framework\Data\Collection\AbstractDb $resourceCollection = null, array $data = [] ) { 此构造函数（Magento\Framework\Model\ResourceModel\AbstractResource，Magento\Framework\Data\Collection\AbstractDb）中有两种类型提示，它们不是 Magento对象管理器接口。它们是抽象类。当我扩展此类并尝试添加注入的依赖项时 class Foo extends Magento\Framework\Model\AbstractModel { …
2
为什么有些类在其构造函数和di.xml中都定义了注入？
我不明白为什么在某些类中，它们的依赖项注入要声明两次-一次在di.xml和具体类的构造函数中进行。 例如，在中Magento\Backend\Model\Url，di.xml已定义了以下用于DI的类型集： <type name="Magento\Backend\Model\Url"> <arguments> <argument name="scopeResolver" xsi:type="object"> Magento\Backend\Model\Url\ScopeResolver</argument> <argument name="authSession" xsi:type="object"> Magento\Backend\Model\Auth\Session\Proxy</argument> <argument name="formKey" xsi:type="object"> Magento\Framework\Data\Form\FormKey\Proxy</argument> <argument name="scopeType" xsi:type="const"> Magento\Store\Model\ScopeInterface::SCOPE_STORE </argument> <argument name="backendHelper" xsi:type="object"> Magento\Backend\Helper\Data\Proxy</argument> </arguments> </type> 但是同时，在其具体类中，在注入中需要在di.xml中定义的那些类在构造函数中再次声明： <?php public function __construct( \Magento\Framework\App\Route\ConfigInterface $routeConfig, \Magento\Framework\App\RequestInterface $request, \Magento\Framework\Url\SecurityInfoInterface $urlSecurityInfo, \Magento\Framework\Url\ScopeResolverInterface $scopeResolver, \Magento\Framework\Session\Generic $session, \Magento\Framework\Session\SidResolverInterface $sidResolver, \Magento\Framework\Url\RouteParamsResolverFactory $routeParamsResolverFactory, \Magento\Framework\Url\QueryParamsResolverInterface $queryParamsResolver, \Magento\Framework\App\Config\ScopeConfigInterface …
2
如何在Magento 2的当前订单发货中添加跟踪号？
我确实找到了Magento 1.x的示例代码。但是我不知道如何在Magento 2上执行此操作。 谁能描述如何使用依赖注入（DI）来实现这一点？ 谢谢。 $trackingDetail = array( 'carrier_code' => 'ups', 'title' => 'United Parcel Service', 'number' => 'TORD23254WERZXd3', // Replace with your tracking number ); $track = Mage::getModel('sales/order_shipment_track')->addData($trackingDetail); $shipment->addTrack($track); $transactionSave = Mage::getModel('core/resource_transaction') ->addObject($shipment) ->addObject($shipment->getOrder()) ->save();
1
Magento 2：虚拟类型命名约定
日期：2015年6月1日（考虑到Magento 2不断变化的性质） 在Magento 2中，您可以在模块的配置文件中配置“虚拟类型”di.xml。这些虚拟类型使您可以更改特定注入依赖项的参数。 在Magento 2的核心代码中，虚拟类型似乎有两种命名约定。首先，虚拟类型的名称看起来与真实的PHP类名称相同。 #File: app/code/Magento/CatalogRule/etc/di.xml <virtualType name="Magento\Catalog\Pricing\Price\Pool" ... 在第二个中，使用了一个简单的无反斜杠的字符串 #File: app/code/Magento/CatalogSearch/etc/di.xml <virtualType name="advancedSearchFilterList" ... 上面两个命名约定有什么实际区别？例如，您选择的名称是否virtualType会对它的行为产生影响，或者仅仅是一个全局唯一的字符串来标识该类型，以便以后使用。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.