Struggling with MageBridge
Wednesday, 09 September 2009MageBridge is cool. It not only integrates Magento users and Magento content in Joomla!, but it offers all the other aspects of integration as well. We'd like to see MageBridge not as a neat shaving machine, but as a swiss-army knife. The issue here is that you know where to find the cutting knife or the scissors, but what are all those other things for?
We are struggling with several things in MageBridge. In our opinion, building a bridge between two applications is a bit more than just writing a generic piece of software. There are many opportunities when Joomla! and Magento are combined. But is it wise to implement all these new features? Let's take a look at the problems we (Yireo) are having.
Simplicity or functionality
One of the major downsides of MageBridge, is that the more functionality we put in it, the more complex it becomes. Adding more features might be needed for the things you might need to configure, but every time a little checkbox is added to the configuration it adds the complexity.
The best way to deal with this is by saying: If you don't know what it is, don't configure it. All the fundamental settings should be well documented and easy to find. But all the more complex settings should be separated from the rest. In general, we use documentation for this: Our MageBridge Quick Start Guide lists all the needed settings to get the bridge up and running, our MageBridge tutorials (only accessible for customers) lists all exceptions and extra possibilities.
The problems start already when installing MageBridge. Getting a HTTP-based bridge up and running seems simple, but we have seen already so many misconfigurations of hosting environments which make setting up the bridge not an easy task. Though we provide direct support to any customer experiencing problems, we are also struggling with the question how to make the setup go as flawless as possible. By doing that, we have to anticipate any kind of weird Apache-configuration an administrator might have setup - it complicates things a bit.
Combined theming
But that's just the struggle we have with ease-of-use. Another problem that comes along is combined theming - the principle of combining a Magento theme with a Joomla! template. The main benefit for combined theming is that things work right out-of-the-box, you don't need to build anything from scratch.
The downside here is that some things in the Magento theme might conflict with the Joomla! template. Think about HTML-elements with the same ID or class, but also of CSS-styling. If you add CSS to Joomla! to fix one bug, it might cause another bug in the Magento styling.
Because this problem is different for every set of Joomla! template and Magento theme, we can't offer a generic solution. What we can do, is offer generic tools that will help the webdesigners to do their job. These tools are both configurable options in the MageBridge GUI as well PHP-functions in helper-classes.
But no matter what we come up with, the problem remains that combining the two applications will require extra work in the themes. This will only be solved if somebody decides to offer fully functional Joomla! templates with MageBridge support.
The JavaScript problem
Part of the problem of combined theming, is the combination of JavaScript frameworks. Magento uses the JavaScript framework Prototype and Joomla! uses MooTools. Unfortunately those two bite: They can not be combined on one page, period. The solution would be to remove either MooTools from Joomla! or Prototype from Magento.
Neither option is easy. But while MooTools is very popular because of it's easy syntax, many people have already wondered why Prototype is used for Magento: It's difficult to use and it's a very heavy-weight solution. Within the Magento forums there are already discussions on how to remove Prototype from Magento (and for instance replace it with jQuery). We intend to take part in this discussion, and hopefully add a solution to the conflict between MooTools and Prototype.
Third party integration
Integrating third party extensions (either in Joomla! or Magento) was one of our first goals while developing MageBridge. We looked for a generic way of providing integration options to third party developers as well, and found it in the event-systems that both applications use. By forwarding a Joomla! event to Magento and vice versa, we built a mechanism that allows a developer to communicate with the other end through MageBridge.
While events are limited in Joomla!, there are numerous events in Magento. Worse, in Joomla! the events are well documented, in Magento they are not. Forwarding all events is not easy and not recommendable. There for, we have chosen to only forward a certain set of Magento events to Joomla!. However, third party developers can still add their own event to be forwarded as well.
Event forwarding
Forwarding the event sounds easy and offers many options to integrate third party extensions. But when diving into this matter, some important questions popup: What if a Magento event is forwarded to Joomla! which triggers a Joomla! event being forwarded to Magento? Should this event forwarding go on forever? Another issue is performance: Every time an event is forwarded this causes extra bandwidth (thus time) to be used. Which events are usefull and which are not?
Because event forwarding is pretty revolutionary, we are still experimenting with it. One-way event forwarding (in which an event is forwarded to the other end but no feedback is sent back) is simple and powerful. For instance, an integration between Magento and Community Builder only needs this functionality. But bi-directional forwarding in which feedback is being sent back to the source or in which a counter-event is being forwarded, is more complex and also needs to be well-implemented.
An example: While buying the MageBridge product in our Yireo Shop, an event is generated that the checkout has been completed. This event is forwarded from Magento to Joomla! and picked up by a custom Joomla! plugin. This plugin adds the Joomla! user (which equals the Magento customer) to the appropriate Joomla! membership (a third party extension). But if this fails, we want to send feedback to Magento to change the status of the order. This again would trigger a Magento event when saving the order, which is forwarded back to Joomla!. Where does it end? In the end, we decided not to change the status of the order, to prevent "endless-event-forwarding-loops" and bad performance.
When MageBridge becomes more wide-spread, we expect also event forwarding to be picked up by other developers. So we as Yireo probably have the responsibility of not only documenting the principle of event forwarding, but as well explaining the Magento and Joomla! events and bringing real-life examples to ease implementation.