タグ付けされた質問 「dependency-injection」

で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">

41 magento2  dependency-injection  virtualtype 

Magento 2には、事前に生成された、またはその場で生成された多くのクラスファイルが含まれています。彼らが住んでいます var/generated これらの生成されたファイルには、ファクトリクラスが含まれます。ドキュメントから、プログラマーはファクトリクラスを使用して「注入不可能な」オブジェクトをインスタンス化することを理解しています。「非注入可能」オブジェクトとは、通常、インスタンス化にユーザー入力が必要なため、依存性注入を介して追加できないオブジェクトです__constructor。 ドキュメントから明らかでないのは、Magento 2がファクトリクラスを生成する必要があることをどのように認識するかです。このビット ランタイムモードまたはコンパイラのオブジェクトマネージャが存在しないファクトリに遭遇した場合、オブジェクトマネージャはファクトリを生成します。 オブジェクトマネージャー（または拡張機能により、依存関係の挿入__constructors）でファクトリクラスを使用すると、Magento 2がそれを生成するように聞こえます。しかし、オブジェクトマネージャーは、私が要求しているのがファクトリーであることをどのようにして知るのでしょうか？ また、生成されたすべてのクラスを自動的に生成（または「コンパイル」）するための2つの コマンドがあるようです。これらのコマンドのいずれかを実行すると、多数のファクトリクラスが生成されます。 必要なファクトリオブジェクトを生成するために、これらのコマンドはどの構成ファイルやコードファイルを調べていますか？ オブジェクトマネージャやコマンドコードを最後までたどることでこれが明らかになることはわかっていますが、長くて骨の折れる旅を避けたいと思っています。

39 magento2  compiler  dependency-injection  factory 

Magento 2の最新ビルドは、このMageクラスを廃止しました。これは、Mage::helperメソッドを失ったことを意味します。 Magento 2でヘルパーをインスタンス化するための代替技術（ヘルパー工場？）はありますか？それとも私たちは、新しいオブジェクトマネージャクラスを使用して、ただでシングルトン/キャッシュされたオブジェクトとしてヘルパーをインスタンス化することが期待されているget（対create）

26 magento2  helper  dependency-injection 

そのため、ほとんどのモデルとブロックでは、コンストラクターの最後のパラメーターとしてこれが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 ); } また、好みを扱うとき、あなたは とき、元のコンストラクターよりも多くのパラメーターを追加する場合、そのパラメーターをコンストラクターパラメーターリストの最後に保持する必要があるいます。 したがって、この配列に関していくつかの質問があります： それは何ですか ？ それの使い方 ？ パラメータを追加するブロックの設定を宣言するときに、コンストラクタパラメータリストの最後に保持する必要があるのはなぜですか？

21 magento2  php  dependency-injection  di  preference 

たとえば、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（同じコンストラクターに他のものがあることは知っていますが、私が考えるすべてのケースに1つの説明が当てはまります）。 di.xmlコアモジュールによると、varは次のインスタンスになりますMagento\Framework\App\Config。 <preference for="Magento\Framework\App\Config\ScopeConfigInterface" type="Magento\Framework\App\Config" /> 必要に応じて簡単に変更できます。 コードでそのようなインターフェイスを使用する必要があるのはいつですか？ …

19 configuration  magento2  best-practice  dependency-injection 

だから、Magento 2のプロキシクラスとは理論的には知っています。それについての素晴らしいAlan Stormの記事を読み、それらのクラスがどのように生成されるかを完全に理解しています。 しかし、それは私が英語を母国語としないからなのか、アランの説明が非常に抽象的な非コアクラスを使用しているのかわからないが、それがどのように機能するのか、特に使用するタイミングを理解するのに苦労している開発中。 それでは、次のコアからこの例を見てみましょう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> 私が知りたいのですが： なぜ特定のケースでプロキシクラスが使用されるのですか？ 一般に、プロキシクラスを使用する必要がある場合

17 magento2  dependency-injection  di  proxy 

このスレッドが言ったように：Magento 1のMagento 2で抽象クラスをオーバーライド、 完全に新しいクラスを作成できます。Magento 2では、プラグインを使用する必要がありますが、プラグインでは既存のメソッドを変更することしかできません。新しいメソッドを追加する場合はどうすればよいですか？ 例： このクラスvendor/magento/module-ui/Component/AbstractComponent.phpには、コンポーネントの配列があります：$components、その配列の要素を設定/削除する機能はありません。それでは、どうすればその関数を作成できますか？

16 magento2  overrides  dependency-injection 

\ Magento \ Framework \ View \ Element \ Templateではないブロックを拡張しようとするたびに、Magento 2の依存関係の注入をブロックで把握するのに苦労しているようです。 Magento \ Theme \ Block \ Html \ Header \ Logoの非常に基本的なブロッククラスを拡張するブロックを作成したい-コンストラクトメソッド内で依存関係の注入を試みるまで、すべてが正常に機能します。 <?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, $data); …

15 magento2  blocks  class  extend  dependency-injection 

私はポイントを逃しているかもしれませんが、なぜ特定のクラスに「使用」ステートメントがあるのか​​、時にはないのか疑問に思っています。 例：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に、コンストラクターパラメーターで実行できることが明確にわかります。 私の質問は： なぜ1つのクラスだけでこれを行うのですか？ useコンストラクターのすべてのクラスにステートメントを追加して、完全なクラスパスを入力する必要がないのはなぜですか？ または、逆に、useステートメントを削除してStoreManagerInterfaceクラスへのフルパスを入力してみませんか？

14 magento2  dependency-injection  di 

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で仮想タイプクラスをオーバーライドする適切な方法は何ですか？

13 magento2  module  blocks  overrides  dependency-injection 

製品リポジトリーを挿入したいコントローラーアクションがあります 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の依存関係注入は、productRepositoryPHPがスローする引数および引数エラーに対して常に無効なクラスを挿入します。storeManagergetdだけで罰金を注入しました。キャッシュをクリアしても解決しませんでした。 スローされる例外は次のとおりです。 Recoverable Error: Argument 3 passed to Nosto\Tagging\Controller\Export\Test::__construct() must implement interface Magento\Catalog\Api\ProductRepositoryInterface, …

12 magento2  controllers  dependency-injection  action 

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オブジェクトマネージャーインターフェイスではない 2つのタイプヒントがあります（Magento\Framework\Model\ResourceModel\AbstractResource、Magento\Framework\Data\Collection\AbstractDb）。それらは抽象クラスです。このクラスを拡張し、注入された依存関係を追加しようとすると class Foo extends Magento\Framework\Model\AbstractModel …

12 php  magento2  dependency-injection 

一部のクラスで、依存関係の注入が2回宣言されている理由がわかりません。1回目di.xmlは、具体的なクラスのコンストラクターで宣言されています。 でたとえばMagento\Backend\Model\Url、そのは、di.xmlDIのためのタイプのこのセットが定義されています： <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 …

12 magento2  magento-2.1  dependency-injection  di 

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();

10 magento2  shipping  dependency-injection  shipment-tracking 

日付：2015年6月1日（変化するMagento 2の性質を考慮して） Magento 2では、モジュールの構成ファイルで「仮想タイプ」をdi.xml構成できます。これらの仮想タイプを使用すると、特定の注入された依存関係の引数を変更できます。 コアMagento 2コードでは、仮想タイプに2つの命名規則があるようです。最初の例では、仮想型の名前は実際のPHPクラス名と同じように見えます。 #File: app/code/Magento/CatalogRule/etc/di.xml <virtualType name="Magento\Catalog\Pricing\Price\Pool" ... 2番目では、単純なバックスラッシュのない文字列が使用されます #File: app/code/Magento/CatalogSearch/etc/di.xml <virtualType name="advancedSearchFilterList" ... 上記の2つの命名規則に実際的な違いはありますか？つまり、選択した名前virtualTypeはその動作に影響を与えますか、それとも後で使用できるようにタイプを識別するグローバルに一意の文字列です。

10 php  magento2  dependency-injection  virtualtype