Magento source model conventions

Question

I often see two different methods in a source model that appear to do the same thing:

class Mypackage_Mymodule_Model_Source_Generic {

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

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

}

In my experience, there's no rhyme or reason as to when which method name is employed; they both appear to return the same data structure.

Is there something I'm missing?

Is there semantic link between a source model's toOptionArray and Varien_Data_Collection::toOptionArray?

Answer 1

Like so many of my answers, this is informed speculation.

The toOptionArray and getAllOptions "source model" split seems like another case of too many chefs in the Magento 1 kitchen. That is, a team of developers working with similar concepts, but with no one in charge of making sure the end result was a solid, consistent system. The problem is there's (at least) two kinds of "source models" in Magento.

First, there's a source model concept in the system configuration system (system.xml files, System -> Configuration, etc) which dictates the options for the system configuration forms. Second, there's a source model concept (more accurately, an attribute source) in the EAV system which, again, dictates options for UI forms, but this time for rendering user interfaces to edit object entries that have a particular attribute.

The system configuration system uses toOptionArray. The EAV system uses getAllOptions. This is reflected in the interfaces provided for the EAV system's source attribute objects.

#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);
}

More importantly than that though is how the objects are used by the system. When Magento renders the UI in the system configuration tabs, it does so with this code

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

When Magento renders the UI for editing an EAV product object, it does so with code like this

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

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

So that's two different system developers implementing a similar concept in different parts of Magento. So, when other developers need to create a UI with a select list and aren't intimately familiar with the system conventions, they pick the method they've seen before, which is what leads to the (seemingly) no rhyme or reason pattern you mentioned above. There's also a few cases where Magento core developers working on features have tried to marry the two methods.

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

Finally, while there's no official semantic link between Varien_Data_Collection's toOptionArray and the toOptionArray used in the system configuration source models, it seems safe to speculate that since the source models are, in practice, collections of data, that a core developer chose toOptionArray as the method name so (in theory) a Varien_Data_Collection based object could be used as a source model. I suspect if not for performance considerations in PHP 5.2, the models in app/code/core/Mage/Adminhtml/Model/System/Config/Source all would have inherited from Varien_Data_Collection.