Est-il possible de pré-générer du code pour un module spécifique? IE - Je peux générer tout le code du système avec php bin/magento setup:di:compile Cependant, cela peut prendre beaucoup de temps. Je voudrais pré-générer uniquement les fichiers d'un module spécifique. php bin/magento setup:di:compile Pulsestorm_Commercebug Le problème spécifique que j'essaie de …
J'ai donc remarqué que dans la plupart des modèles et des blocs, ce array $data = []paramètre est le dernier paramètre du constructeur . Par exemple \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 …
Dans Magento 2 (presque) tous les arguments répertoriés dans les fichiers xml ont un attribut xsi:typequi détermine comment la valeur de l'argument est interprétée. Par exemple, dans le di.xmlfichier du module backend il y a ceci: <argument name="scopeType" xsi:type="const">Magento\Framework\App\Config\ScopeConfigInterface::SCOPE_TYPE_DEFAULT</argument> cela signifie que la valeur de l'argument scopeTypeest la valeur de …
Donc, je sais théoriquement ce qu'est une classe proxy dans Magento 2. J'ai lu le génial article d'Alan Storm à ce sujet et je comprends parfaitement comment ces classes sont générées. Cependant, et je ne sais pas si c'est parce que je ne parle pas anglais ou si les explications …
Je manque peut-être un point, mais je me demande simplement pourquoi il existe parfois une instruction "use" pour une classe spécifique et parfois nous ne le faisons pas. Exemple:, app\code\Magento\Email\Model\Template.phpnous avons en haut du fichier: namespace Magento\Email\Model; use Magento\Store\Model\ScopeInterface; use Magento\Store\Model\StoreManagerInterface; Ensuite, dans la __constructméthode, nous avons les paramètres suivants: …
Je ne comprends pas pourquoi, dans certaines classes, leurs injections de dépendances sont déclarées deux fois - une fois dans le di.xmlconstructeur de la classe concrète. Par exemple dans Magento\Backend\Model\Url, son di.xmla cet ensemble de types pour DI défini: <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> …
J'ai actuellement les éléments suivants <preference/>dans l'un de mes fichiers di.xml: <preference for="Magento\Contact\Controller\Index\Post" type="RadTest\TestModule\Controller\Contact\Post" /> J'ai une option de configuration activer / désactiver pour mon module dans le panneau d'administration. Je souhaite que l' <preference>option soit activée uniquement lorsque mon option de configuration personnalisée est définie sur activé. Comment puis-je …
Dans Magento 2.3, il existe des interfaces pour tous les verbes http Magento\Framework\App\Action\HttpPostActionInterface Magento\Framework\App\Action\HttpGetActionInterface, ... Tous sont vides et implémentés Magento\Framework\App\ActionInterface. J'ai également constaté que tous sont mappés dans app/etc/di.xmlun paramètre de Magento\Framework\App\Request\HttpMethodMapet de nombreux contrôleurs implémentent ces interfaces. Mais pas tous les contrôleurs. C'est tout ce que j'ai pu …
Je vois dans les di.xmlfichiers du noyau que certains des arguments ont le type init_parametermais les valeurs des paramètres sont toutes des constantes. <type name="Magento\Framework\View\Page\Config\Renderer"> <arguments> <argument name="appMode" xsi:type="init_parameter">Magento\Framework\App\State::PARAM_MODE</argument> </arguments> </type> ou celui-ci <type name="Magento\Framework\App\Cache\State"> <arguments> <argument name="banAll" xsi:type="init_parameter">Magento\Framework\App\Cache\State::PARAM_BAN_CACHE</argument> </arguments> </type> et plein d'autres. Mais d'après ce que je vois …
En ce moment, je suis ennuyé d'écrire des constructeurs similaires en masse comme les suivants dans mes modules. public function __construct( \Magento\Framework\Model\Context $context, \Magento\Framework\Registry $registry, /* ... */ \Foo\Bar\Model\Baz $baz, /* ... */ \Magento\Framework\Model\ResourceModel\AbstractResource $resource = null, \Magento\Framework\Data\Collection\AbstractDb $resourceCollection = null, array $data = [] ) { $this->registry = $registry; …
Les traits fonctionnent-ils réellement avec l'injection de dépendance dans Magento? Considérez le code suivant: Classe de caractère namespace Frame\Slick\Block; use Frame\Slider\Slick\Block\Data as Helper trait Slick { protected $_slickHelper; public function __construct(Helper $slickHelper) { $this->_slickHelper = $slickHelper; } } Classe utilisant le trait namespace Frame\Slick\Block; class Product ListProduct implements BlockInterface { …
We use cookies and other tracking technologies to improve your browsing experience on our website,
to show you personalized content and targeted ads, to analyze our website traffic,
and to understand where our visitors are coming from.
By continuing, you consent to our use of cookies and other tracking technologies and
affirm you're at least 16 years old or have consent from a parent or guardian.