We’re currently busy finalizing a major refactoring of our Ext Scheduler component which will be released as v2.2. There are two major reasons for this refactoring. First of all we needed to refactor to enable certain pieces of the core functionality to be shared with our Touch Scheduler. These bits of code relate to non-UI parts of the component, such as stores, models, utility classes etc. The second reason for the refactoring, was to future proof the component a bit and clean up as many Ext JS overrides as possible. With the recent Ext JS 4.2 beta releases, too many things broke that should not break.

Global Ext JS overrides

In the latest official version of Ext Scheduler, things are pretty much under control. There’s a large unit test suite covering loads of scenarios and the component is very stable. For example, we’re testing that no global variables are leaked. We also scan the entire Ext JS source tree to find any global overrides of the Ext JS library (a bad practice we used in older versions).

We don’t write code like this anymore. Override code like this introduces a lot of uncertainty and is just as bad as regular global variables. As a component maker, we should not make any changes to our ‘surroundings’. Thanks to our zero-tolerance test, any attempt to make a global Ext JS override will now break our build. You can check how the test is performed in our test named /tests/sanity/012_no_overrides.t.js .

Overriding private Ext JS methods

Another aspect of overrides is when you override a private method in a subclass (see code below). When faced with a tricky problem, this can be tempting since there is nothing stopping you in the world of javascript and Ext JS. But overriding non-public and non-documented methods will likely lead to problems, maybe not tomorrow – but at some point. It happened to us quite frequently with each new version of Ext JS we had to support. At too many places we had simply overwritten private Ext JS methods, whose implementations then changed slightly in newer releases.

The snippet above looks harmless but it could very well lead to an issue if the shouldUpdateCell method is renamed or removed from the Ext GridView class. Overrides like this should be considered as the last resort to solve a particular problem. If there is a way to solve the issue by relying on the public Ext JS API instead it is definitely preferred. In real life applications, it’s hard to completely avoid doing such overrides though, so how do you best deal with these overrides? We already tried ignoring the overrides, and it turns out that ignoring a problem doesn’t really solve it. :)

Dealing with overrides

In our upcoming 2.2 version, each override of a private method is annotated with a // @OVERRIDE comment to warn anyone reading the code. If unit tests start breaking when we try a new version of Ext JS, those methods are prime candidates to review. This however is not enough, we can do better. I just wrote a simple Siesta unit test that will help us identify our weak spots as we upgrade to newer versions of Ext JS. It turned out to be very easy:

The test isn’t 100% fool proof, you could still override classes at run time that won’t be detected by this test (though that is a very unusual practice). Running this test against the latest official Ext Scheduler release reports 65 overrides, which is waaaay too many. This is very clear proof and it explains why we’ve been experiencing painful upgrades. After our 2.2 refactorings, the result looks a lot better:

We have now brought it down to 9 overrides, which is a lot more manageable. For an extremely small investment (the test took me < 1hr to write) we now have a very good overview of our component weak spots when it’s time for the next upgrade. As the 2.2 version relies a lot more on the public API, upgrading to and supporting new Ext JS versions should hopefully be much easier.

How do you deal with overrides in your application? Please share any tips you have in the comments section?

  1. Brian Moeskau 01/31/2013, 7:50 pm Reply

    Yes, this is a pain point for me too, and I still have global overrides that lead to other bugs as things change. I’ll take a deeper look at this approach myself and will likely crib some of your tests!

  2. Mats 01/31/2013, 8:53 pm Reply

    Sounds great, let us know how it works out. All our tests can be inspected in the /tests folder! :)

  3. We’re a bunch of volunteers and starting a new scheme in our community. Your website provided us with valuable info to work on. You have performed a formidable process and our entire group shall be grateful to you.

Leave a Comment

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> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>