Don’t be afraid to have fun
Sometimes an idea just pops into my head, and it’s so absurd that I immediately dismiss it. Sometimes I’ve had a couple of beers, and so I don’t dismiss it quite as quickly…and that’s a very good thing.
An idea is born
There is always a lot of discussion around designing versus testing at Inviqa. In a conversation with a colleague last year, we discussed how much of a Magento module we should be testing, and how up front design and unit tests should mainly support the domain layer of the application. We were talking about reducing the temptation to mock Magento objects by properly separating the application layer (the module) from the domain implementation.
Shortly after this conversation I attended a company event in London, and after a few company sponsored drinks I boarded a train back to the north with grand ideas of domain libraries being loaded into Magento modules. The part of this that I wasn’t comfortable with was the strong coupling that I could envisage between a Magento object and a domain object. Simply put, because Magento has no easy way of injecting dependencies, and it’s object locator only works within the confines of its own module structure, modules would have to explicitly construct their own library dependencies. Boo.
What I wanted was proper DI in Magento, but I only had 2 hours on the train so I decided to compromise and opt instead for giving Magento some service location capabilities. What I wanted was fairly simple:
- Dependencies loaded with Composer must be available to Magento without a lot of effort
- There should be an easy way to access dependencies within a Magento module that would look familiar to Magento developers
Making it happen
After a bit of investigation I realised that this wasn’t something that I could easily achieve, so I broke the first rule of working with a framework and started to edit the framework code. In order to add a new static method to Mage that would allow service location — Mage::getFromContainer() — I needed to redefine the Config object that sits behind all of those static helper methods. I then edited index.php so that if Composer’s autoload file exists it would be required, and if my extended Config class is found then it would be enforced during the bootstrapping process. Finally I added the new static method to Mage.php.
By this time my train was pulling into York, and so I closed my laptop went home and went to bed. The next day I spoke to my colleagues jokingly about what I’d got up to the previous night, how much or ridiculous hack it was, and then promptly forgot all about it.
The payoff
Skip forward a couple of months, and a couple of guys on my team were starting to investigate using message queues in Magento, and were wondering how to bridge the gap between their module and their AMQP library without forming strong coupling. I gave them a link to my fun little experiment on Github, hoping they might find some part of it interesting. Amazingly they ran with it, and implemented it in our client’s project. Even better, they improved it and sent me a pull request back!
So, from a slightly tipsy thought of “haha, I wonder if…” a real solution to a problem was born. What I’ve learned from this is that it’s important to pursue those thoughts whenever they occur, because you never know where they might lead. And you’ll probably get to have some fun along the way.
