In addition to enabling new features and capabilities, another goal of Ext JS 4 was to streamline the overall API and make it more consistent. Given these goals, it was not possible to maintain full backward compatibility with Ext JS 3. However, we definitely recognize the need to make transitioning to Ext JS 4 as smooth as possible for our community.
We are very pleased to introduce several new resources that will assist in migrating existing Ext JS 3 applications to Ext JS 4, and will hopefully minimize the difficulty and effort involved. These are bundled in our new Ext JS 3 to 4 Migration Pack, the components of which are outlined below.
- Ext JS 3 Compatibility Layer
- Ext JS 3 to 4 Migration Guide
- Ext JS Migration Demo App
- Ext JS Migration Screencasts
Download the Ext JS 3 to 4 Migration Pack (Updated October 20, 2011)
Table of Contents
Ext JS 3 Compatibility Layer
This consists of a set of files that, when included after Ext JS 4, provide overrides that will bootstrap existing Ext JS 3 code to run under Ext JS 4. The goal of this layer is not to enable your application to run unmodified under Ext JS 4 long-term. On the contrary, you should expect to use this layer only as a temporary means of migrating fully to Ext JS 4. The purpose of providing it is to help make the transition as swift and painless as possible. Rather than debugging obscure errors from a blank screen, you will be able to get your application back into a rendered and functional state much more quickly using the compatibility layer, making it dramatically easier to start migrating to the latest architecture.
Ext JS 3 to 4 Migration Guide
This guide, included with the compatibility layer download, lays out the high-level steps required to upgrade an Ext JS 3 application to Ext JS 4. It does not cover every possible detail about what changed from Ext JS 3—no single guide could do that for such a massive release. Because of that, there are specific guides for charting, tree, grid, and more that are great additional resources to use when upgrading specific components. See the new Ext JS 4 documentation center start page for all of the available guides.
In the vast majority of cases, the compatibility layer handles aliasing and overriding things so that Ext JS 3 applications can become functional under Ext JS 4, but there are some cases where this is simply not possible. The Migration Guide outlines the main areas that will require manual updating outside of the compatibility layer in order to get your app up and running quickly.
Ext JS Migration Demo App
We’ve also included a 3-part demo application with the download that shows off the usage and benefits of the compatibility layer. The application includes many of the most common components running properly under compatibility mode including a tree, tab panel, grid, window, form, chart, data stores, border layout, and more. The download includes:
- A basic application is written in standard Ext JS 3.3.1
- The same application running under Ext JS 4 + the compatibility layer. Minimal modifications were required in the application code to make this work, and these are noted in the source comments. You can run this version of the app in the browser and examine the kinds of warnings presented in the browser console by the compatibility layer.
- The same application fully migrated to Ext JS 4 with no compatibility layer. This version also runs under the new Ext JS 4 class system and uses the new dynamic loader to determine file dependencies automatically at runtime.
Ext JS Migration Screencasts
As a companion to the downloadable Migration Pack, we’ve also produced a 2-part tutorial screencast that will walk you through step-by-step how to migrate an application to Ext JS 4. The first tutorial introduces the compatibility layer into the demo Ext JS 3 application and demonstrates making the app run correctly under Ext JS 4 in compatibility mode. The second tutorial focuses on migrating off of the compatibility layer to run fully under Ext JS 4 and covers all of the changes required in the demo app to do so. It also demonstrates how to convert Ext JS 3 custom classes to the new Ext JS 4 class system and how to leverage the new dynamic loading scheme in your own application.
View the video tutorials: Ext JS 3 to 4 Migration Screencast Part 1 | Part 2
The compatibility layer and migration guide do not currently provide 100% of possible coverage of the API changes in Ext JS 4. Due to the sheer amount of effort and complexity involved in mapping all of the API’s that changed across the entire framework, the compatibility layer has by necessity been trailing the changes to the framework itself. However, because many people are ready to dive into Ext JS 4 today, we wanted to make these resources available as soon as possible.
Development on the Migration Pack will continue for now, with additional update releases, until it reaches the point where most of the API that can be mapped is mapped. We’ll never get to 100%, but we can get pretty close. There are bound to be questions and issues that arise once people start testing this out. Please use the Ext JS 3 to 4 Migration thread on the Sencha Forum as your primary source for discussing migration issues, rather than posting questions here in the blog comments.
As always, we welcome your feedback, and we hope that these resources will help everyone to quickly upgrade to the latest and greatest framework that Sencha has to offer!
Florian Cargoet says
This migration pack must have been a lot of work! We appreciate the effort!
Awesome work Brian. Made my life easier.
Mitchell Simoens says
Great work and great write up! Wasn’t expecting the screencasts!
Steffen Hiller says
That is the way to go! Push everyone to migrate to Ext 4. :)
rox this kind of efford for the comunity, updating 4 all, ExtJScellent!
Does anyone else think it’s quite weird that Mitchell, who is working for Sencha, is commenting and praising their own work? Maybe it’s just me but I don’t find it very objective nor professional.
@devnullable Mitch wasn’t developing Ext JS 4 directly, right Mitch? He has done a huge amount of bug reporting and fixing to help Ext JS 4 get stable sooner for you to use it.
I don’t think this is a good place for throwing rocks at anyone. Just remember, the choice of using this awesome open source framework is yours. You are always welcome to contribute in a constructive fashion.
Great work Brian. And you also have a great talent for making videos. Cudos!
I understand we fellow Vikings meet in Split. See you there.
Andrew Peacock says
Great news: this is the type of thing that makes the Sencha offering much more than just the ExtJS code itself.
Keep it up!
Evan Trimboli says
@Devnullable I see nothing wrong with it. I work with Sencha as well and I think Brian has done a great job on this, he deserves the congratulations.
What’s wrong with complimenting your colleagues?
Loiane Groner says
Greak work Brian! Thank you!
Your contact formular is not working so I post my message here.
Lots of your Ext JS 4 Demos are not working because the loading script is broken. I included some explanations below.
I hope that it will be fixed soon.
The bootstrap.js script is broken. This script tries to find its path by looking to the loaded scripts and finding itself. Then it extracts the path and load the “ext-all.js” script. But in the examples this scripts fails to find its path and tries to load the “undefinedext-all.js”. This is because the “bootstrap.js” script looks for a script whose path ends by “bootstrap.js” but in the deployed examples it ends with “bootstrap.js?sfgdata=+sfgRmluamFuX1R5cGU9amF2YV9zY3JpcHQmRmluamFuX0xhbmc9dGV4dC9qYXZhc2NyaXB0+q”.
@Evan Nothing wrong with complimenting the colleague. My bad, I didn’t realize praise was directed to Brian. Nothing to see here, move along :) Sorry Mitch.
Jonathan Griffin says
Awesome work! Thanks for this migration path. It will help us immensely as we migrate our existing SaaS application and customer base to ExtJS 4.
Tobias Uhlig says
just watched your first video and i like it.
I think it will help a lot of community members with not too many custom ux, components and overrides to get a good start into the ext js 4 world :)
Wonderful job Brian! I specially loved the videos. :-)
Hi Brian, Excellent tutorial. You should start a new product line (video tutorials) about how to use ExtJS 4 :)
George Jempty says
@Evan Trimboli: “What’s wrong with complimenting your colleagues?”
If you’re colleagues, you can compliment them in private. When you do so in public, without revealing that you are colleagues, it smacks of “self”-aggrandizement, where the “self” is Sencha
From what I’ve seen of ExtJS4 and its documentation so far, if I were not working at a company that is already committed to using ExtJS, I would be recommending taking a serious look at alternatives. I think Sencha needs some serious competition from another framework, because ever since Jack Slocum has left, I think your product has become sloppier and sloppier
I am in the throws of converting a fairly complex application from 3.3 to 4.0 and I’m seeing some odd behavior. All of my panels render fine by themselves after migration but when I try to load them all on a single page, they are all mixed up. The first panel gets clobbered by the second panel and the third panel gets clobbered by the fourth, etc. It looks like they are overwriting parts of each other. Fields from one panel end up on a different panel. A panel renders correctly and then a split second later, it’s a mess.
Luis Carlos Moreira da Costa says
Gajanan Borde says
Really excellent work …
Fantastic framework and I love it but, such big changes in every release is killing many of us in large firms. Imagine going to the business and saying “hey we just put your application into production, now you need to pay for us to migrate it to a new extjs version”. Please do not pull me down with statements such as “use it only if you want to”. Are we going to see this pattern in every major release going forward too?
Seeing “ExtJs was poorly designed from the very beginning” and later “switching to a more mature framework, or even developing a wrapper around other lighter and stabler libraries such as jQuery” is… not very accurate.
ExtJs design was UI, and not Model oriented. It suffices to look at the extensive changes in Grid and DataModel to see what was wrong. For example the Record validation is done in the UI, more specifically in the Form. If you need to change a record in other way than trough the UI, you will have to duplicate the code for validation. Also the validations rules can be different for update and insert. If you change a field name, you have to modify in the at least three places, Grid, Form, Store. If you used more than a couple of grids and forms in an application, you should be already aware about these problems. To avoid such things we designed our own data model library, but now we have to rewrite it to make it compatible with ExtJs4.
Even from UI point of view there are mistakes, for example you don’t have a class that could act seamlessly as a command button or menu item depending on the container. If you need both a button and a menu item, you have to create and maintain each one separately or write your own class.
Sergey Borovsky says
Not a slightest chance that our application is going to be migrated from 3 to 4 with this simple migration package. We’re using (rightly or wrongly) DWR for AJAX. That’s where EXTJS 4 stops working from very beginning.
… “Even from UI point of view there are mistakes, for example you don’t have a class that could act seamlessly as a command button or menu item depending on the container. If you need both a button and a menu item, you have to create and maintain each one separately or write your own class.”…
You do not have to create a “new class” to handle this… you use Ext.Action and create many menus or buttons from the action….
That’s going to make things a lot esaier from here on out.
Really good work brain…
I have >20 years experiance in Smalltalk and about 1 year in Ext 3.
But of course, for USA people it’s always a huge problem and matter of pride to optain things from Europe. The “not invented here syndrom”. We know…!