Ext JS 4 is the most comprehensive upgrade to the framework we’ve ever released. From completely overhauled packages like Data and Charting to widgets like the Tree and Grid that were rewritten from the ground up, you may also test it with Javascript Grid Performance Analyzer, which enables users to evaluate the Ext JS Grid performance on various benchmarking metrics.. Ext JS 4 represents a new level of power and flexibility in RIA development.
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)
Learn the latest about Ext JS and HTML5/JavaScript for three intensive days with 60+ sessions, 3+ parties, and more at SenchaCon 2013. Register today!
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
Continued Improvement
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!
What's your reaction?
0
0
This migration pack must have been a lot of work! We appreciate the effort!
Awesome work Brian. Made my life easier.
Great work and great write up! Wasn’t expecting the screencasts!
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.
Great news: this is the type of thing that makes the Sencha offering much more than just the ExtJS code itself.
Keep it up!
Regards,
Andy
@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?
Greak work Brian! Thank you!
Your contact formular is not working so I post my message here.
Hello,
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”.
Best regards
Cedric Finance
@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.
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.
Hi Brian,
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 :)
Best regards
Tobias
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 :)
@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.
Any suggestions?
Hi Brian
@Excellent Tutorial
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?
@Anon: The truth is that ExtJs was poorly designed from the very beginning and there where no choice than complete redesign of some modules, of course with the price of sacrificing compatibility. I am in the same situation as you and I don’t know if I will ever upgrade. JavaScript is not Java or C++ where compiler does most of the job, you need very skilled developers to overpass the lack of tools. We also have some applications written in ExtJs2, that will never by upgraded. Rewriting a corporate applications from scratch every year because of unstable framework features is very expensive, and you will never get budget for that since the application is working fine in the eyes of the management. We are considering switching to a more mature framework, or even developing a wrapper around other lighter and stabler libraries such as jQuery. or Prototype.
@anonim
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.
@lossendae
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.
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.
@anonim
… “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…
Excellent work…
I have >20 years experiance in Smalltalk and about 1 year in Ext 3.
Looking at Ext 4, I get the impression that you have learned and re-used a lot from Smalltalk – and that is very good, because this “granny” is stil superior to all the kiddies, including JavaScript.
As for your “OO JavaScript” you would have better re-used a German development called JOOP, which has it all (and more?). It was made by a Smalltalker (not me).
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…!
Deadlink!