OptionArray or 'poor man entity relations'?

[greenwellness]

Ok I've shortened the OT a bit to provide a more terse explanation of the initial idea.

1. take a entity/object of the kind which implements toOptionArray()
2. have it populate multiselect list with entities
3. store those entity values as a comma separated list of integers to explode after retrieval
4. provide a 'templated' string URL source which will interpolate the integer values at desired position
5. render the final list in a columns as <a href="http://domain.tld/store/domain/entity/id/{{.}}/view" ...>..</a>, <a href="" ...> elements

A few comments, pro's and con's noted:

• we will definitely not need all elements with toOptionArray() - checked with grep -ERn 'function toOptionArray(). Some interesting ones are listed below.
• since we do not want to display all varien collections that have optionArray but also do not want to exclude any e.g. community or local entities
• due to the Magento core override system functioning this wouldn't pose a codepool problem since local always wins and should be used anyway - retrieval is dynamic anyway so whoever wins, wins.
• the major cultprit, as is now with option array, is any syntax errors, typos or non-existing attributes reference - which of course will expose itself during script interpretation only given its dynamic nature - and as such, nothing we can do about anyway to prevent people from making mistakes. This is significantly different from the rest of the module creator in the sense that you are in full control of the generation process.
• agreed that the entire list as selection (of toOptionArray() function definitions) would screw up the intent (80% is garbage anyway) - wonder if anything weighs up the trouble of hinting the user of any potentially interesting option arrays

That last point made me think on whether it would need to be multi-selectable values/controls and if that needs to make sense.

For example: while it might make sense to apply Mage_Api2_Model_Acl_Global_Rule_Privilege (array of class constants) multiple times on a custom entity, it would be much of a corner case, perhaps only if the entities are constraints or rules applied on entities which would have properties exposed via REST, but highly unlikely. Also multiselect of e.g. Language/Collection items wouldn't make much sense unless they'd be applied to individual entities, not as a whole on a single entity. That is to say, if the custom entity would be an abstraction of pages and that particular field would be the languages available to translate content... anyway you get my drift. Rather far fetched use-cases imho.

A few indeed, should probably be of more interest but, again, one doesn't exclude the other per se.

• Orders
• Order Items (very desirable as Mage doesn't allow much interaction afterwards with those does it?)
• CMS Pages
• Order status
• Websites/stores
• Templates

Orders problem is: Magento doesn't really support it (which doesn't mean they can't be included via simple integer to route URL interpolation and im-/explosion of the elements

Downloadable/Model/System/Config/Source/Orderitemstatus.php +36 Adminhtml/Model/System/Config/Source/Order/Status.php +43 Sales/Model/Resource/Order/Status/Collection.php +49 CatalogInventory/Model/Source/Backorders.php +29

Composing orders programmatically is hard, but retrieval relatively very easy. Same goes for CMS pages and a few other things so yeah, I guess they may be good candidates.

[tzyganu]

Holy smokes Batman. You really took the time to write an issue, didn't you? Let me summarize what you wrote, to see if I got it right. So you want as a source model for dropdown and multiselect attributes anything that has the method toOptionArray. This means every class that extension Varien_Data_Collection. I don't think this is such a good idea. Well, the idea is good, but the 'all' part is not. I'm not sure what the exact number it is, but for sure there are over 100 such classes. This would make the dorpdown reaaaaly long and unfriendly. I agree that some of them could be useful, like the list of cms pages or cms blocks, but some you will never use. (polls for example). Others should not be used at all. For example orders. If you have an attribute in your custom entity where you need to select an order or mode, after some time your add/edit entity page will crash, because you have too many orders to render.

I will try to add other source types for dropdown attributes but for sure it will not be all of them.

[greenwellness]

I updated and summarized/cleaned up a bit. Last entry actually made me think about another angle, probably better in its own thread.