Sencha Inc. | HTML5 Apps

Blog

Ext Scheduler 2.0—Upgrading to Ext JS 4

September 26, 2011 | Mats Bryntse

Bryntum In my previous post I introduced you to the Ext Scheduler, an Ext JS component for scheduling tasks and resources. At Bryntum, we have since then been busy upgrading our code base to Ext JS 4. While we upgraded our scheduler and Gantt components we also took the opportunity to re-factor our code to make use of the new capabilities in Ext JS 4.

In the previous scheduler version, several key parts of the component relied on third party extensions such as LockingGridView, ColumnHeaderGroup, Maxim’s TreeGrid and Saki’s Ext.ux.form.DateTime. It’s a major step forward for us to have that functionality available natively in Ext JS 4, and we’re very happy that our components are now 100% based on code supported by Sencha. Here’s a look at the 2.0 scheduler version which uses the new Ext TreePanel.

New TreeView for Scheduler 2.0
New TreeView for Scheduler 2.0

A look at the new Ext JS GridPanel and TreePanel

The GridPanel is more or less completely rewritten in Ext JS 4. The old Ext JS 3 grid worked pretty well for simple use cases but combining multiple features was not easy. If you have ever tried to combine locking columns, grouped rows and grouped headers you know what we mean. Supporting these multiple GridView configurations was previously a big headache for us at Bryntum and it led to quite a bit of code duplication. In order to extend the GridView with our scheduling functionality, we had to create separate view classes for each combination of these view types, leading to confusing class names such as ‘Sch.LockingGroupingSchedulerView’. On top of that, we needed to use the Ext.grid.EditorGridPanel class whenever we wanted to add inline cell editing.

In Ext JS 4, there is only a GridView and a TreeView and we can easily add our scheduling API to these two different views by using mixins. This minimizes code duplication and makes code a lot more pleasant to maintain.

Another nice thing is that the locking grid is now composed of three separate panels; one panel that contains two child GridPanels (or TreePanels):

Ext JS 4 locking grid panel
Ext JS 4 locking grid panel

Now our users can configure the left and right grids independently. In the first screenshot, the locked TreePanel is configured to be collapsible and the containing panel is using a border layout instead of the default locking hbox layout. Here’s the simple code used to set it up:

var tree = Ext.create('Sch.panel.SchedulerTree', {
    title       : 'Airport departures',
    width       : 900,
    height      : 400,
 
    layout : 'border',
 
    schedulerConfig : {
        header : false,
        region : 'center'
    },
 
    lockedGridConfig : {
        header : false,
        split: true,
        width : 200,
        region : 'west',
        collapseDirection : 'left',
        collapsible : true
    },
New Vertical Axis for Scheduler 2.0
New Vertical Axis for Scheduler 2.0

Many of our users requested making the locked grid collapsible so we’re happy we could add that feature with very little effort. Adding this feature to our Ext JS 3 version using the old LockingGridView extension would have been much harder; requiring a lot more code and increasing our code maintenance burden.

Another frequently requested customer feature was the ability to flip the horizontal view to show resources on the horizontal axis and time on the vertical axis. With Ext JS 4, this was easy to implement and we added this feature in our 2.0 version.

What we learned upgrading from Ext JS 3

Upgrading our components to Ext JS 4 naturally required quite a bit of work. This is to be expected whenever you create custom components which rely heavily on the markup and functionality of a certain Ext JS class. You can be especially vulnerable if you override internal methods and use undocumented members of a class. We started our upgrade journey by going piece by piece, and class by class. But without proper testing, we soon found it hard to validate that we had upgraded a class successfully. Unit testing JavaScript and UI behavior can be tricky especially if a particular class depends on several other classes and application state. But about half way through our upgrade we realized that we badly needed unit tests to validate that our existing APIs and features had no regressions. So we used a JS unit testing tool built by our own Nickolay Platonov over the past two years and optimized it for testing Ext JS applications.

Developing our Ext JS code in a test driven fashion completely changes the game for us and our new testing tool (codename ‘Siesta’) helped us a great deal in making sure that we didn’t break our code without knowing about it. Thanks to PhantomJS, we could also run our tests as part of our continuous integration process. If you want to try a beta version, come talk to us at the upcoming SenchaCon in Austin, Texas.

After successfully upgrading all the parts of the Scheduler, we could finally render it and interact with it. At this point we looked at supporting the new dynamic class loading in Ext JS 4. This required us to follow certain conventions for our class names and folder structure. Converting our code base to support dynamic loading forced us to rethink our class structure and organize our classes in a cleaner way. For each class, we had to explicitly state which external classes it depended on (by using the ‘requires’ array). But finding questionable class dependencies is easy when you see it expressed clearly. As an extra bonus, we also saw time savings when debugging using dynamic loading because we no longer needed to search within a monolithic JS file. If you haven’t yet started using dynamic loading, we strongly recommend that you do so: you will save lots of time.

Summing it up…

The upgrade to Ext JS 4 turned out to be a challenge for us because the native Ext JS grid was rewritten and the scheduler uses grid as its base class. We also hit a few rough edges (mainly involving CRUD operations) in using the functionality in the new tree. However, we were able to sort out just about all our issues by using a few overrides. But it’s an area in which improvements would be very welcome. In retrospect, upgrading to the new Ext JS version was definitely worth the effort and our refactored code base has matured a lot on the new platform. Next up we’ll be looking at porting our components to Sencha Touch 2.0 and we’re very much looking forward to its release.

Additional resources:

There are 8 responses. Add yours.

Michael Camden

3 years ago

We have also been looking for an ExtJS testing tool. Is ‘Siesta’ available to the general public?

Mats

3 years ago

@Michael, not yet - we’re still polishing it. Next week we’re about to start a private beta, contact me if you want to help test it.

Chris

3 years ago

Has your code base shrunk for Ext 4 compared to the one for Ext 3? Does Ext Scheduler perform faster/more responsive now that the code base uses Ext 4?

Mats

3 years ago

@Chris: Our 2.0 code base would have shrunk if we hadn’t added support for vertical orientation and TreeView. Regarding performance, our 2.0 is performing about the same as 1.x. We actually have both our 1.x and 2.x examples hosted online so you can easily compare yourself smile

Simo Moujami

3 years ago

@Mats: I’m very interested in trying out “Siesta”. Can we touch base?

Mats

3 years ago

@Simo: Sure, send me a PM in our forums (mats). http://www.bryntum.com/forum

Mikhail Khodos

3 years ago

Wow! Krasnodar city on the screenshot! Greetings from there smile

toddriehle

2 years ago

Very Interesting to know about Ext Scheduler upgrade

Comments are Gravatar enabled. Your email address will not be shown.

Commenting is not available in this channel entry.