Соглашения об исходных моделях 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 Сплит "исходная модель" кажется еще одним случаем слишком большого количества поваров на кухне Magento 1. То есть, команда разработчиков работает с похожими концепциями, но никто не отвечает за то, чтобы конечный результат был надежной, последовательной системой. Проблема в том, что в Magento есть (по крайней мере) два вида "исходных моделей".

Во-первых, в системе конфигурации системы есть понятие исходной модели (system.xml файлы, System -> Configurationи т. д.), который определяет параметры для форм конфигурации системы. Во-вторых, в системе EAV существует концепция модели источника (точнее, источника атрибутов), которая, опять же, диктует параметры для форм пользовательского интерфейса, но на этот раз для визуализации пользовательских интерфейсов для редактирования записей объектов, имеющих определенный атрибут.

Система конфигурации системы использует toOptionArray, Система EAV использует getAllOptions, Это отражено в интерфейсах, предоставленных для объектов атрибутов источника системы EAV.

#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 отображает пользовательский интерфейс на вкладках конфигурации системы, он делает это с помощью этого кода

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

Когда Magento отображает пользовательский интерфейс для редактирования объекта продукта EAV, он делает это с помощью кода, подобного этому

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

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

Так что это два разных системных разработчика, реализующих похожую концепцию в разных частях Magento. Поэтому, когда другим разработчикам необходимо создать пользовательский интерфейс со списком выбора, и они не очень хорошо знакомы с системными соглашениями, они выбирают метод, который они видели ранее, что и приводит к (на первый взгляд) шаблону рифмы и рассуждений упомянутое выше. Также есть несколько случаев, когда разработчики ядра 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"s toOptionArray и toOptionArray использованный в исходных моделях конфигурации системы, можно с уверенностью предположить, что поскольку исходные модели на практике представляют собой наборы данных, выбранный основным разработчиком toOptionArray как имя метода так (в теории) Varien_Data_Collection основанный объект может быть использован в качестве исходной модели. Я подозреваю, что если бы не соображения производительности в PHP 5.2, модели в app/code/core/Mage/Adminhtml/Model/System/Config/Source все бы унаследовали от Varien_Data_Collection,