Replace hard coded "new Varien_Image" with "Mage::getModel('core/image')"

[woutersamaey]

I want to suggest replacing the hard coded "new Varien_Image" with "Mage::getModel('core/image')", so loading of these models can be done the Magento way.

Never understood why Magento didn't do this to begin with.

This way, other modules can rewrite these models and do some new things.

We are already doing this is our projects and have implemented cloud file storage this way. Currently using patches to make the core edits. Yeah :(

The new class Mage_Core_Model_Image just extends the old, so nothing would break.

Like this, other models like Varien_Io_File and Varien_Image_Upload would also be replaced the same way.

If the community agrees, I'll build it.

[Flyingmana]

Does getModel work with non module classes as in Mage::getModel('Varien_Image')?
While I dont see a reason against it, I would like to first check

1. is there a way to not create a new Class in Modules
2. how does Magento2 solve it?

Also are there any other possible cases we should think about?

out of curiosity, what is the usecase you need for changing this models?

[woutersamaey]

• Erm, this is not how Magento works.
• Magento 2 has the ObjectManager & DI
• Why changing the model? I told you in the description: to build cloud storage that does not need underlying disk based storage. Typical & previous solutions would extends the DB file storage, but that still writes a lot to the disk giving little benefit. If we can replace these models, we can remove the "media" dir entirely. That's just one example.
• Would also love to implement resizing using Imagick instead of GD. That also comes into play at some point.

[Flyingmana]

I investigated the getModel resolution quite intensive a few years back. Internally the Module/Classname is just a reference and normally you can also use full class names.
see https://github.com/OpenMage/magento-lts/blob/1.9.4.x/app/code/core/Mage/Core/Model/Config.php#L1344
I just do not remember, if this also worked for classes, which do not belong to a module, and if the class rewrite does work for them.

If the rewrite would not work with them, we could introduce a pseudo class, which does not exist, but using a rewrite to point to the Varien_Image, as the rewrite logic uses full class names.

Would it be also enough, if just the Image Adapter would be properly configurable?
I remember changing from GD to Imagick is a common Issue, so w need a solution for this anyway

We also have already plans to introduce support for DI(there was a working solution for M1 someone already had) but thats more far away.

Doing the change for Varien_Io_File seems harder, because of the big number of uses in different contexts.