Question

after reading this tweet from Ivan Chepurnyi and having to add a step to the OnePage Checkout (aka OPC) for a client’s site, I thaught it was the perfect occasion to learn something new.
I am a big fan of events/observers and try to use them as much as possible, but precisely for the OPC so far I found that it was not very elegant to use them. I mean, there are no useful events (as far as I know) that can be used.

For example, from the top of my head I think of 2 things that I have to change and are very easy with a rewrite while it would be over complicated with event/observer:

1. steps: Mage_Checkout_Block_Onepage::getSteps() defines the different steps that composes the OPC. I really can’t see what event would allow me to change that
2. goto: when one step is completed the Mage_Checkout_OnepageController‘s corresponding action returns the html for next step along with the goto_section and update_section data. Again, I don’t see any interesting event

And this is just without really looking into every detail I’ll have to implement, I guess there are more pitfalls.
Same thing for the javascript part: I am used to extend the checkout js class:

var MyModule = Class.create(Checkout, {
    //write some code here
});

but I wonder if there is a better way.

I realize that Ivan’s tweet is meant for PSP devs, and that I am working for a final client, but I’d like to learn something new

Answer 1

Main idea of the tweet was about most of the developers who develop custom payment methods don’t care about conflicts with other modules or customizations you have on the website.

Onepage Checkout Steps

As for your first step, it is a problem of Magento core, that it has all checkout steps in _getSteps() method are hardcoded and you cannot change it without override.

Controller Overrides

The second one is quite easy to implement even with just using of controller_action_predispatch and controller_action_postdispatch actions.

On preDispatch Magento gives you a lot of freedom to control the flow of controller action by using controller flags like FLAG_NO_DISPATCH, FLAG_NO_PRE_DISPATCH and FLAG_NO_POST_DISPATCH.

On postDispatch you can modify existent result by modifying body of the response object. In case of returned JSON, you can easily transform this data back to array, modify it and set back as JSON.

Yes this solution might more complex to implement, but it increases your module compatibility with the others a lot, since you are safe with possible overrides of the same controller by other module.

JavaScript Customizations

As for JavaScript, you should always consider that it is dynamic language and there is no class itself on language level, everything is an object and you are always can extend existing functionality via replacing existing object prototype with own implementation by using assignment of variables:

window.Checkout = Class.create(Checkout, {
      someMethod: ($super, param1, param2) {
          // Do you custom staff before
          $super(param1, param2);
          // Do you custom staff after
      }
});

In the following example prototype of Checkout “class” is gets replaced by your instance, that customizes its someMethod functionality. $super variable contains Function object of parent “method”, that gets overwritten and it will work with the same kind of customization to the same class of another method (or even the same one), because it just modifies only property that contains that method definition.

If you’d like to read more about this JS language functions please refer to this website: http://www.crockford.com/javascript/javascript.html