-
-
Save Vinai/5cc7396efbd9c818dd54 to your computer and use it in GitHub Desktop.
<?php | |
// I almost never use $installer = $this; instead I prefer to use the following | |
$installer = Mage::getResourceModel('catalog/setup', 'catalog_setup'); | |
// This is just an example of instantiating the setup class in the script. Of | |
// course I choose the appropriate setup class and resource on a case by case basis. | |
// That way it is very visible what setup class is being used. It can also be | |
// switched within a single setup script, for example to add attributes to | |
// catalog_product and customer entity types. | |
// Also, PHPStorm + Magicento give the IDE knowledge what the returned type is, | |
// even without a phpdoc type hint. | |
$installer->startSetup(); | |
$entity = array( | |
'entity_model' => 'example/foo', | |
'table' => 'example/foo', | |
); | |
$installer->addEntityType('foo', $entity); | |
... | |
$installer->endSetup(); | |
// Instantiating the setup class in the script resolves the issue that | |
// the type is defined or might be invalid after configuration changes. | |
// For that reason I see no additional benefit in adding an IIFE for | |
// for type safety. | |
// Regarding the scoping of variables in the setup script, using a custom | |
// setup class with custom methods is PHP 5.2 compatible and fits the OOP | |
// architecture of Magento more closely. | |
// If lots of data is needed, that can still be supplied to the setup class | |
// methods as arguments (i.e. the usual Magento configuration arrays), or | |
// a specific, one-time custom setup class could be used. | |
// (Personally I also find the PHP IIEF syntax with call_user_func ikky :)) | |
// Regarding a method not warrinting a class of its own, usually I try to | |
// keep classes as small as possible. Single method classes are find, but | |
// actually are very rarely needed. |
I share your feeling regarding wanting to "wrap" code somehow, be it a function or a class.
My comfort is that it is wrapped inside the method call in the setup class. Not much comfort though.
When using a framework I generally try to stick with it, trying to use it in the way it is supposed to be used.
For one I hope to benefit from the consistency myself, and of course I would like it if other developers have an easier time reading my produce. So thats my reasoning why I try to do things the way I do.
When it comes down to it, I think the IIFE are fine, except for support of ancient but officially supported PHP versions.
Regarding your question, without a <class>
node in the config.xml the detault class Mage_Core_Model_Resource_Setup
witll be used as the default setup class.
I'm not aware of any resources recommending that approach besides the official Magento U developer trainings that I give :)
Oh, and you are right in that I usually don't specify that <class>
node in my config XML.
I think part of the reason I like something wrapping the script, IIFE or otherwise, is just me feeling a little icky about "bare" php in a file; call it cargo-culting, if you want. (I don't really like bare phtml templates, either, but don't worry, I haven't made those IIFEs. :P) I don't love
call_user_func
syntax, but it still seems the lesser of evils to me.I like your idea of instantiating the setup class in the script, but doesn't that introduce the possibility of a discrepancy between what
/config/global/resources/*/setup/class
says and what your script actually does? Or do you just never putclass
in config.xml anymore? Are there any Magento books or guides that actually recommend this approach?