就像我的许多答案一样,这是有根据的推测。
与“源模型”toOptionArray
的getAllOptions
分裂似乎是 Magento 1 厨房中厨师过多的另一个案例。也就是说,一组开发人员使用类似的概念,但没有人负责确保最终结果是一个可靠、一致的系统。问题是 Magento 中有(至少)两种“源模型”。
首先,系统配置系统(system.xml
文件System -> Configuration
等)中有一个源模型概念,它规定了系统配置表单的选项。其次,EAV 系统中有一个源模型概念(更准确地说,是属性源),它再次规定了 UI 表单的选项,但这次是为了呈现用户界面以编辑具有特定属性的对象条目。
系统配置系统使用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 在系统配置选项卡中呈现 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
最后,虽然在系统配置源模型中'stoOptionArray
和toOptionArray
used之间没有官方语义联系,但可以推测,由于源模型在实践中是数据的集合,核心开发人员选择toOptionArray
作为方法名称,因此(理论上)Varien_Data_Collection
基于对象可以用作源模型。我怀疑如果不是出于 PHP 5.2 中的性能考虑,app/code/core/Mage/Adminhtml/Model/System/Config/Source
所有模型都会继承自Varien_Data_Collection
.