Magento 源模型约定

Question

我经常在源模型中看到两种不同的方法，它们似乎做同样的事情:

class Mypackage_Mymodule_Model_Source_Generic {

  /* I sometimes see this method */
  public function getAllOptions() {}

  /* And other times this method */
  public function toOptionArray() {}

}

根据我的经验，何时使用哪个方法名称没有任何押韵或理由；它们似乎都返回相同的数据结构。

我有什么遗漏的吗？

源模型的 toOptionArray 和 Varien_Data_Collection::toOptionArray 之间是否存在语义链接？

Answer 1

就像我的许多答案一样，这是有根据的猜测。

toOptionArray 和 getAllOptions“源模型” split 似乎是 Magento 1 厨房中厨师过多的另一个案例。也就是说，一组开发人员使用类似的概念，但没有人负责确保最终结果是一个可靠、一致的系统。问题是 Magento 中(至少)有两种“源模型”。

首先，系统配置系统中有一个源模型概念(system.xml 文件、System -> Configuration 等)，它规定了系统配置的选项形式。其次，EAV 系统中有一个源模型概念(更准确地说，属性源)，它再次规定了 UI 表单的选项，但这次用于呈现用户界面以编辑具有特定属性的对象条目。

系统配置系统使用toOptionArray。 EAV 系统使用getAllOptions。这反射(reflect)在为 EAV 系统的源属性对象提供的接口(interface)中。

#File: app/code/core/Mage/Eav/Model/Entity/Attribute/Source/Interface.php
interface Mage_Eav_Model_Entity_Attribute_Source_Interface
{
    /**
     * Retrieve All options
     *
     * @return array
     */
    public function getAllOptions();

    /**
     * Retrieve Option value text
     *
     * @param string $value
     * @return mixed
     */
    public function getOptionText($value);
}

比这更重要的是系统如何使用对象。当 Magento 在系统配置选项卡中呈现 UI 时，它会使用以下代码来实现

#File: app/code/core/Mage/Adminhtml/Block/System/Config/Form.php
//...
$optionArray = $sourceModel->toOptionArray($fieldType == 'multiselect');
//...

当 Magento 呈现用于编辑 EAV 产品对象的 UI 时，它会使用如下代码来实现

#File: app/code/core/Mage/Adminhtml/Block/Catalog/Product/Edit/Tab/Super/Config/Simple.php

'values' => $attribute->getSource()->getAllOptions(true, true),

因此，这是两个不同的系统开发人员在 Magento 的不同部分实现了类似的概念。因此，当其他开发人员需要创建带有选择列表的 UI 并且不太熟悉系统约定时，他们会选择他们以前见过的方法，这就是导致(看似)没有押韵或原因模式的原因上文提到的。在一些情况下，从事功能开发的 Magento 核心开发人员尝试将这两种方法结合起来。

#File: app/code/core/Mage/Tax/Model/Class/Source/Product.php
public function getAllOptions($withEmpty = false)
{
    //...
}
//...
public function toOptionArray()
{
    return $this->getAllOptions();
}

最后，虽然 Varien_Data_Collection 的 toOptionArray 和系统配置源模型中使用的 toOptionArray 之间没有官方语义链接，但似乎可以安全地推测，由于源模型实际上是数据集合，因此核心开发人员选择 toOptionArray 作为方法名称，因此(理论上)是一个基于 Varien_Data_Collection 的对象可以用作源模型。我怀疑如果没有 PHP 5.2 中的性能考虑，app/code/core/Mage/Adminhtml/Model/System/Config/Source 中的模型都会继承自 Varien_Data_Collection。