Blog: Thinking Out Loud

Musings on (Magento) Life, the (.NET) Universe and Everything (IT)

One of the best things about working in magento is that if you are comfortable with an object oriented style, you start seeing patterns everywhere. If a new functionality calls for it, you can add a child class and with a little bit of magento-xml-config-magic, you can add virtually (well, concretely) anything new by replacing the existing class.Recently, one of the interesting things one of our clients asked us to do was to add an extra column in the orders grid in the magento admin.

This translates into modifying the Mage_Adminhtml_Block_Sales_Order_Grid class. So if we do a little bit of OOP-ing over here, this just means that we have to override this class and add our own.

Step-1: Creating a module

1. Creating your own folder directory under local. I used local/RLTSquare/MyModule.

2. Registering your module with magento. This is a simple matter of creating an RLTSquare_MyModule.xml file under etc/modules, with the following text:

3. Create a config.xml file under local/RLTSquare/MyModule/etc, with the following text in it:

Step-2: Overriding the class

1. Add a node in our config.xml file (just under the root ‘config’ node) that we created above:

2. Create a file named Grid.php under local/RLTSquare/MyModule/Block/Sales/Order. I will skip the reasoning behind these particular names and directory structures, though magento veterans will recognize the order in this (apparent) chaos.

3.Finally, let’s bring our attention to the Grid.php file. This will contain our overridden class.

And this is where the trouble will begin.


The Problem with the Solution

You see, the problem is that in the last line of _prepareCollection, when you call the parent class function to in the end to let it do what it wants with the $collection variable, it completely overwrites it, thus rendering our extra lines of code irrelevant. A little bit of debugging will show that our code in this function, despite being run properly, is absolutely useless when the variable is reassigned in the parent class.

What to do now? A little bit of googling led me here, to this great blog piece by the people at Inchoo. The solution described here works perfectly, with one very nagging issue: Instead of overriding the class that actually needs to be overridden, they override its parent and then copy all the relevant code into their own custom class, before adding their own. This seems horribly un-OOP-ish and I can’t come to terms with this. Not to mention the fact that if the original code changes due to a magento upgrade, our overridden file would have to be coded again.

So, is there a better way? The way I chose to do it was that instead of calling the parent class function at the end, I called the grandparent class function by the following line of code:

This way, my new class gets to have only the minimum amount of code that it needs, and the problematic piece of code (which I do not need) is bypassed. I think this is much more elegant solution.

Anyone have any better ideas? Is calling a grandparent function like this not a good idea? Do comment!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">