Questions tagged «best-practice»

表示与Magento中的最佳做法相关的问题。

5
如何编写自定义扩展名?
因为我最近在免费和商业扩展方面遇到了很多问题,所以我决定问这个问题,并按照编写扩展时通常遵循的步骤回答。随时编辑答案或添加新答案。 在大多数情况下,安装扩展程序或主题时,我必须花费几个小时(有时更多,有时更少)才能使其在我需要的所有环境中正常工作: dev:通常localhost项目在子文件夹中 预生产和现场 即使来自大型扩展程序提供商的扩展程序,也发生了这种情况(至少应该保持匿名,直到我非常生气并在此处添加其名称为止)。 所以主要问题是..编写扩展程序以确保质量时应考虑哪些步骤?代码,并使技术人员和非技术人员更容易使用它,并使技术人员更容易更改它?

7
Magento 2:直接使用还是不使用ObjectManager?
好的,昨天我们就与Magento社区的其他人就直接使用ObjectManagerclass / templates进行了大讨论。 我已经知道了我们不应该直接使用ObjectManager的原因,并引用了Alan Kent的话: 有几个原因。该代码将起作用,但是最佳实践是不直接引用ObjectManager类。 因为我们这么说!;-)(更好地表示为一致的代码就是好的代码) 该代码将来可以与其他依赖项注入框架一起使用 测试更加容易 -您可以为所需的类传递模拟参数,而不必提供模拟ObjectManager 它使相关性更加清晰 -通过构造函数列表可以清楚地了解代码所依赖的内容,而不是将依赖项隐藏在代码中间 它鼓励程序员更好地考虑诸如封装和模块化的概念 -如果构造函数变大,也许这是代码需要重构的标志 根据我在StackExchange中看到的内容,很多人倾向于使用简单/简短/不推荐的解决方案,例如: <?php //Get Object Manager Instance $objectManager = \Magento\Framework\App\ObjectManager::getInstance(); //Load product by product id $product = $objectManager->create('Magento\Catalog\Model\Product')->load($id); 而不是经历痛苦但推荐的过程: 创建一个模块 宣布偏好 注入依赖 声明一个公共方法 但是,随之而来的难题是,Magento 2核心文件经常直接调用ObjectManager。可以在此处找到一个简单的示例:https : //github.com/magento/magento2/blob/develop/app/code/Magento/GoogleOptimizer/Block/Adminhtml/Form.php#L57 所以这是我的问题: Magento为什么要做他们建议我们不要做的事情?这是否意味着在某些情况下我们应该ObjectManager直接使用Direct?如果是这样,那是什么情况? 直接使用ObjectManager有什么后果?

5
我们何时应该在Magento 2中使用存储库和工厂?
我已经阅读了Magento 2中的一些教程,这让我有些困惑。我可以看到基本上有两种方法可以读取/写入业务实体: 检索数据 使用工厂方法 $object = $this->myFactory->create(); $object->load($myId); 使用存储库方法 $repo = $this->myRepository(); $object = $repo->getById($myId); 保存数据 使用工厂方法 $object = $this->myFactory->create(); $object->load($myId); $object->setData('something', 'somethingDifferent')->save(); 使用存储库方法 $repo = $this->myRepository(); $object = $repo->getById($myId); $object->setData('something', 'somethingDifferent'); $repo->save($object); 我还看到,可以使用依赖项注入来注入存储库和工厂类。至少对我来说这令人困惑。 我们什么时候应该使用存储库方法和工厂方法?我们需要遵循的最佳实践是什么?

6
现代的Magento 1.X工作流程和开发工具
我是Magento Development(CE 1.6)的新手,并且仍在尝试定义我的工作流程。我目前在使用Netbeans 7.3的Mac OSX 10.8上进行开发,但是我发现Netbeans运行缓慢且无法运行。我倾向于切换到Sublime Text 2来快速查看/编辑文件,或者有时为了方便起见我只是拉起Vim。 我的问题: “ 现代的Magento 1.X工作流程是什么样的? ” “ 什么工具/配置/插件最适合Magento开发? ” 我知道这是一个主观的事情,不会有“一个工作流程来统治所有人”,但是我也相信,所有认证/有经验的开发人员都会有一些共同的选择。至少,我希望一些经过实践检验的知识。 我将不胜感激任何输入/反馈/建议。 谢谢!

3
Magento 2无头解决方案
我想知道是否有一些最佳实践将Magento 2用作无头电子商务解决方案。 2017年典型的电子商务是拥有全渠道解决方案,其中包括 电子商务 不育系 多平台 层系统集成(ERP,...) 我想知道如何将Magento 2 API与这种解决方案结合在一起。 我的方法: 对台式机/移动Web应用程序和移动应用程序使用不同的前端框架(例如angular) 仅使用Magento 2 API才能检索电子商务数据/操作或与之交互 仅使用CMS API才能检索CMS数据。 专业版:仅API,全渠道 缺点:性能/功能/格式的局限性 有关此方法的一些问题: 谁负责格式化数据,例如价格。Magento API和前端框架? 谁负责调整产品图像的大小并缓存它们?因为在本地Magento 2 API中没有调整大小或缓存系统。 我是否需要创建新的自定义隔离API或扩展本机以用于将来的升级? 您是否建议使用额外的图层以结合CMS和Magento API? 感谢您分享经验。 此外,我发现了这种方法:http : //fbrnc.net/blog/2015/10/super-scaling-magento 有用的链接: https://blogi.lamia.fi/verkkokaupat/headless-ecommerce/ http://www.magetitans.it/headless-new-buzzword-magento-2-sander-mangel/ https://www.youtube.com/watch?v=6OuzAtqtWRE https://pantheon.io/blog/headless-websites-whats-big-deal-decoupled-architecture http://buytaert.net/the-future-of-decoupled-drupal https://creately.com/diagram/example-v2/ihbyjjkf/Example%20Headless%20Architecture https://www.lullabot.com/articles/should-you-decouple https://alankent.me/2016/12/14/headless-magento-and-extensions/ 编辑: 我找到了一个很好的引导程序,以便为您的Magento 2 API创建自己的缓存逻辑:https : //github.com/magespecialist/m2-MSP_APIEnhancer 编辑: 一个不错的开源项目,目的是将Magento 2用作VueJS …

2
Magento中引发异常的首选方式是什么?
Magento核心使用以下所有方法,因此哪种方法是首选的(或最新的“最佳实践”)方法? Mage::throwException('Some Message')- 732种用法 throw new Exception('Some Message')- 419种用法 throw Mage::exception('Vendor_Module', 'Some Message')- 94种用法 (需要创建一个Vendor_Module_Exception类)

4
有效地从ID获取产品网址
仅给出ID,获得产品网址的最有效方法是什么?在代码的某些地方,我们有一些东西,例如Mage::getModel('catalog/product')->load($id)->getProductUrl()获取产品的URL,鉴于与产品相关的事件数量等等,这似乎很浪费,有没有更简单的方法?还可以指定类别ID的功能很好。 另外,是否有一种有效的方法对商品(例如名称)的单个属性执行相同的操作?

4
在观察者之后返回$ this
我在互联网上以及在第三方模块中都看到了一些冲突的信息- $this在观察者方法结束时返回是一种要求还是最佳实践? 例如: MyCompany_Module_Model_Observer.php public function salesOrderSaveAfter($observer){ //do stuff return $this; }


2
Magento 2-使用/避免使用吸气剂的良好实践?
Varien_Object(M1)和DataObject(M2)上的魔术吸气剂是常见的做法,但是使用Magento 2时,使用它会感到错误。 好: 容易读/写 坏 在键中使用数字时会引起问题(请参阅:Magento 2:使用驼峰式大小写的不同方式获取集合的字段或获取自定义产品属性) 代码分析工具抱怨不存在的方法 题 使用Magento 2,我们有两种新方法: getDataByKey($key) getDataByPath($path) 是否有充分的理由继续使用getData($key)或使用任何吸气剂? 编辑: @Vinai谢谢。我没有提及该@method方法,因为我的方法大不相同。 它仅对IDE有帮助,对其他方面没有影响。 有几个mergedf PR是“微优化”的,例如在循环外(甚至对于小型阵列)强制转换为数组大小或(int)替代intval()数组大小。 另一方面,有 神奇的吸气剂,正如马吕斯(Marius)所说的那样有些“开销”。 strtolower(trim(preg_replace('/([A-Z]|[0-9]+)/', "_$1", $name), '_')); getData($key) Mehtods还必须额外进行2-3次检查... if ('' === $key) { if (strpos($key, '/')) { if ($index !== null) { 对于自己的代码,完全同意倾向于使用实际方法,但是在相同情况下,这是不可能的...例如,您创建了一个自定义事件... $value = $observer->getVar_1(); $value = $observer->getData('var_1'); $value = …

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" /> 但是我可以根据需要轻松更改它。 什么时候应该在代码中使用类似的接口? …

5
在Magento 2中安装第三方扩展的最佳实践是什么?
在为Magento 2进行客户项目工作时-我发现了许多加载并跟踪第三方扩展的方法。 假设我们正在使用集成器安装方法(composer!),那么管理第三方扩展的最佳实践是什么? 到目前为止,我购买或下载的每个扩展都有其自己的composer.json文件-而且我知道扩展作者建议至少三种不同的方式来安装其扩展: 将这些文件复制到应用程序/代码中 将此zip复制到文件夹中,将其添加为工件存储库,并要求它 添加此在线存储库(使用/不使用身份验证)并要求它 到目前为止,我遇到过1和2,只是有点怀疑#3的存在。但是然后,注意到那些建议#1的人,我发现您可以拥有一个“路径”存储库-将扩展从app / code移到了我决定放置这些工件的同一文件夹中,并以此方式要求。 在此过程中,我的存储库配置如下所示: "repositories": { "0": { "type": "composer", "url": "https://repo.magento.com/" }, "artifacts": { "type": "artifact", "url": "artifacts" }, "third-party": { "type": "path", "url": "artifacts/*/*" }, }, 因此,我对您的问题是-最佳做法是什么?您如何管理第三方扩展? 到目前为止,我相信我的方法是最好的方法-仅因为读取了他们的composer.json并且任何依赖关系冲突(或PHP版本约束)都会变得很明显-但我认为这不够确定。

4
Magento 2班级位置和名称的最佳做法
在Magento 1我们习惯于将我们的类放在这些目录中 块 帮手 模型 资源资源 并使用简单的类名,名称中间不要包含任何大写字母。 如果我们看看一些情况 Magento 2 Core 帮手 地点: - \Foo\Bar\Helper 姓名: - *.php 例子: - \Magento\ImportExport\Helper\Report -\Magento\Cms\Helper\Wysiwyg\Images 观察者 地点: - \Foo\Bar\Observer 姓名: - *.php - *Observer.php 例子: - \Magento\CustomerCustomAttributes\Observer\SalesOrderAddressAfterLoad -\Magento\CustomerBalance\Observer\ProcessBeforeOrderPlaceObserver 外挂程式 地点: - \Foo\Bar\Plugin 姓名: - *.php - *Plugin.php 例子: - \Magento\Catalog\Plugin\Block\Topmenu - \Magento\PageCache\Model\App\FrontController\BuiltinPlugin 资料来源:http://devdocs.magento.com/guides/v2.0/extension-dev-guide/plugins.html#declaring-a-plugin …

2
在Magento 2中加载自定义模型的最佳方法
由于我很难找到正确的方法,因此您可以在下面找到我制定的最佳实践。享受,如果需要,请更正我的英语,如果我是我,我就说我错了。:) 编辑: ...,我发现我在某些方面是错误的。因此,在Raphael的答案帮助我了解了更多信息之后,我更新了原始帖子。多亏他! 以下使用的概念: 如果您熟悉以下概念,将更容易理解以下代码和说明: 注入依赖性(因为$this->variable代码中的每个变量都被注入) 服务合同和资料库 厂 内容: 只是为了获得更多的上下文,假设我们有一个可以正确构造的模块: 包含方法的块类CustomBlock getCustomModel($id), 此方法根据在参数中传递的ID返回CustomModel对象, CustomModel类型对应于 \Vendor\Module\Model\CustomModel 此模型带有其资源模型(在中\Vendor\Module\Model\ResourceModel\CustomModel) 及其存储库(在中\Vendor\Module\Model\CustomModelRepository)。 问题: 让所有内容加载CustomModel对象的最佳实践是什么? 由于不建议使用load()此方法,因此不能使用CustomModel对象中的。 优良作法是您必须使用CustomModel服务合同。服务合同是数据接口(例如CustomModelInterface)和服务接口(例如CustomModelRepositoryInterface)。所以我的方块看起来像这样: / ** @var SlideRepositoryInterface * / 受保护的$ slideRepository; / ** * CustomBlock构造函数 * ... * @param CustomModelRepositoryInterface $ customModelRepository * ... * / 公共功能__construct( ... CustomModelRepositoryInterface $ customModelRepository ... …

1
Magento 2中创建多对多关系的最佳实践方法是什么?
我环顾了核心,并看到了几个模型之间多对多关系的一些示例,但是我看不到对此的明确答案。 例如,假设我们创建了一个新模型,并且希望与现有产品表建立多对多关系。 因此,我们有了新的模型-库存商,我们这样创建了2个表,一个表用于存储库存商名称,另一个用于存储与产品的多对多关系。 安装程序类的截断版本: $table = $setup->getConnection() ->newTable($installer->getTable('stockist')) ->addColumn('stockist_id', \Magento\Framework\DB\Ddl\Table::TYPE_INTEGER, null, ['identity' => true, 'unsigned' => true, 'nullable' => false, 'primary' => true], 'Stockist Id') ->addColumn('name', \Magento\Framework\DB\Ddl\Table::TYPE_TEXT, null, ['nullable' => false], 'Stockist Name'); $table = $installer->getConnection() ->newTable($installer->getTable('stockist_product')) ->addColumn( 'entity_id', \Magento\Framework\DB\Ddl\Table::TYPE_INTEGER, null, ['identity' => true, 'nullable' => false, 'primary' => true], …

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.