Sencha Inc. | HTML5 Apps

Blog

Countdown to Ext JS 4: Dynamic Loading and New Class System

January 19, 2011 | Ed Spencer

Countdown to Ext JS 4: Dynamic Loading and New Class SystemToday we're excited to release the first in a series of brand new features in Ext JS 4. Over the next few weeks we'll be rolling out our beta release of Ext JS — package by package. Although we originally planned to release a full beta about now, some parts of the framework have been stabilizing more slowly than expected, so we're going to roll out the packages incrementally instead. Today, we're starting with the brand new Ext JS 4 class system.

JavaScript has no Classes of its own, which can make it an unfamiliar environment for newcomers to the language. Ext JS has always provided a class system of its own which utilizes the language's powerful prototype pattern while enabling developers to write code with a more traditional Object Oriented approach. With Ext JS 4, we're taking the class system to the next level with a series of new features to make your development easier and more flexible. Ext 4 will introduce four new features - class definitions, mixins, setters and getters for configurations, and dependency loading. Class and Relationships in Ext JS 4 The illustration above highlights some of the benefits of our class system, most notably Draggable and Resizable becoming mixins.

Class Definition

To compare, let's take a look at how we used to create a new class in Ext JS 3. In this example, we create a fictional login window class that extends Ext.Window:

 
//Ext JS 3.x class definition
MyApp.LoginWindow = Ext.extend(Ext.Window, {
    title: 'Log in',
 
    initComponent: function() {
        Ext.apply(this, {
            items: [
                {
                    xtype: 'textfield',
                    name : 'username',
                    fieldLabel: 'Username'
                },
                ...
            ]
        });
 
        MyApp.LoginWindow.superclass.initComponent.apply(this, arguments);
    }
});
 
This is probably familiar to most of you and it works well, though it does have some pitfalls. If Ext.Window were not defined when we create our class, we would get an error and our application might crash. Similarly, if the MyApp namespace is not defined we'd also get an error. These problems are both resolved with the new way to define classes:
 
//Ext JS 4.x class definition
Ext.define('MyApp.LoginWindow', {
    extend: 'Ext.Window',
 
    title: 'Log in',
 
    initComponent: function() {
        Ext.apply(this, {
            items: [
                //as above
            ]
        });
 
        MyApp.LoginWindow.superclass.initComponent.apply(this, arguments);
    }
});
 
With Ext JS 4, classes can be referenced by their string name, which means we never get the errors above. The class manager is smart enough to check whether Ext.Window has been defined already, and if not, defer creation of MyApp.LoginWindow until it has been defined. We no longer need to maintain a strict load order in our applications, allowing the framework to take care of everything.

Mixins

This is just the beginning though -- the new class system also brings a series of new features to Ext JS classes. The first of these is the addition of mixins to the framework. Mixins define reusable sets of behavior and configuration that can be 'mixed in' to a class. To take advantage of this new feature in your class, simply apply them in your class definition. For example, to make your class draggable, mix in the Draggable mixin. Any number of mixins can be applied to a class, which makes them a great way to get multiple inheritance - something that has long been difficult to achieve with most JavaScript frameworks. Mixins can be defined like so:
 
Ext.define('Sample.Musician', {
    extend: 'Sample.Person',
 
    mixins: {
        guitar: 'Sample.ability.CanPlayGuitar',
        compose: 'Sample.ability.CanComposeSongs',
        sing: 'Sample.ability.CanSing'
    }
});
 
Once more, all of the class names are referenced by string, so we don't get any errors if the mixins we're using aren't loaded on the page yet. A class can receive any number of mixins and each mixin can be as simple as this:
 
Ext.define('Sample.ability.CanPlayGuitar', {
    playGuitar: function() {
        //code to play 
    }
});
 

Auto Setters and Getters for Configurations

Most of the classes in Ext JS can be customized by passing configuration options. Usually these configuration options can be modified and queried at runtime using getter and setter methods. These have to be maintained and add bulk to the library. Ext JS 4 comes with a special naming convention for configuration options that automatically creates these functions for you. This saves development time, ensures a consistent API and cuts down dramatically on the size of the file download. Let's look at an example:
 
Ext.define('MyClass', {
    config: {
        title: 'Default Title'
    }
});
 
Here we set up the class to receive a single configuration option: title. We also provide a default value for that title, in this case 'Default Title'. With Ext JS 4's new class definition, new getter and setter functions are automatically created. In Ext JS 3.3, we had to manually create this boilerplate code:
 
MyClass = Ext.extend(MyBaseClass, {
    title: 'Default Title',
 
    getTitle: function() {
        return this.title;
    },
 
    resetTitle: function() {
        this.setTitle('Default Title');
    },
 
    setTitle: function(newTitle) {
       this.title = this.applyTitle(newTitle) || newTitle;
    },
 
    applyTitle: function(newTitle) {
         //custom code here
    }
});
 
All four of the functions above are now automatically generated by the framework. In many cases, updating the variable is enough, but sometimes we want to take some special action when we change a configuration. For example if our new class displays its title in a DOM element, we can tell it to update that element by defining it like this:
 
Ext.define('MyClass', {
   extend: 'MyBaseClass',
 
    config: {
        title: 'Default Title'
    },
 
    applyTitle: function(newTitle) {
        Ext.get('titleEl').update(newTitle);
    }
});
 
All four of these functions are generated automatically and we can override any of them as easily as we did for applyTitle above. Not only does this save you writing a lot of code in your own classes, it also significantly cuts down on the size of Ext JS and your application, meaning a smaller file download for your users.

Dynamic Loading

We've looked at just a few of the benefits offered by the new class system -- there are many more that we'll cover later on. But now it's time to introduce something brand new for Ext JS 4: dynamic loading. In every version of Ext JS so far, you've had to load the entire framework before using any of it. If you wanted to create an Ext.Window, it had to be downloaded already or you'd get an error. That all changes with dynaming loading in Ext JS 4. It's as simple as this:
 
Ext.require('Ext.Window', function() {
    new Ext.Window({
        title : 'Loaded Dynamically!',
        width : 200,
        height: 100
    }).show();
});
 
Here we ask Ext JS to load the Ext.Window class and then call a function when it is loaded. We can require any number of classes by passing an array to Ext.require. This just works -- it's very easy, but the real magic is under the covers. The Ext JS 4 dynamic loader is purely client-side -- it requires no server-side installation. What's more, it automatically resolves any dependencies that the loaded class has. As an example, let's say Ext.Window looks like this:
 
Ext.define('Ext.Window', {
    extend: 'Ext.Panel',
    requires: ['Ext.util.MixedCollection'],
    mixins: {
        draggable: 'Ext.util.Draggable'
    }
});
 
As soon as Ext JS loads the Ext.Window class, it figures out the dependencies listed in the extend, requires and mixins declared in the class. If any of these are not already present on the page, it will fetch them first before defining the Ext.Window class. The loader automatically knows how to figure out the file name for each class based on a simple convention. In this case, the following files will be loaded before our function is called:
  • src/Window.js
  • src/Panel.js
  • src/util/MixedCollection.js
  • src/util/Draggable.js
The Loader is recursive -- if any of those files have dependencies that are not already satisfied it will keep loading files until everything is present. While you should avoid taking a file-by-file approach in production, this is immensely useful in solving one of the longest-standing irritations in developing with Ext JS - using ext-all-debug.js. Until now we've recommended using ext-all-debug.js in development and ext-all.js in production. The debug file contains the whole framework in a readable format, but is over 60,000 lines long. This can make it difficult to debug problems - a stack trace telling you there was an exception on line 47657 of ext-all-debug.js is not especially helpful. Using the dynamic loader, the problem will be reported as line 56 of src/data/JsonReader.js, with a full stack trace and correct line numbers for each file. This is a massive step forward when it comes to debugging your applications and it performs extremely well: while developing locally it's hard to tell that the framework is being loaded dynamically. The loader also provides deadlock detection, and can be used to load files both synchronously and asynchronously. And if all that doesn't entice you, don't worry -- the new class system is completely backwards compatible. Your old classes created with Ext.extend will still work, and we will continue creating the ext-all.js file which contains the entire framework.

Live Demo

We've prepared a very simple live demo for you to experiment with and placed it online. The examples start simple and get slightly more involved as they advance. The complete example can be downloaded as a zip file and run locally where you can experiment with the code yourself - all you need is a web server to serve the files for you. The new class system is the basis of a massively enhanced framework for Ext JS 4. Every important class in the framework has been upgraded to be faster, more robust and easier to develop with. Over the next few weeks we'll be introducing the advances one package at a time as we continue our countdown to Ext JS 4. Check back later this week for a look at the amazing new data package for Ext JS 4.

There are 108 responses. Add yours.

Valentin

4 years ago

Wow, cant wait for this!

@JavaScript
  Mixins > Classical inheritance

galdaka

4 years ago

Good work with Ext JS 4!!!!

pablo

4 years ago

Is there a standard for naming my own configuration options?
For example, if I’m extending Ext.Panel and adding subtitle:‘something’ I can’t know for sure that Ext won’t add a config option with the same name in the future.

Dynamic loading sounds nice but does it worth to add it just that it’ll be easier to debug?
Is there some real value in production?

Rodrigo

4 years ago

I process my files on PHP before return them in my dynamic load, for this I call one PHP function and pass the file name. With the ExtJS.require would be can work in this way?

Aaron Conran

4 years ago

@Pablo In addition to being easier to debug, Ext can now calculate the necessary dependencies client-side. With this ability and dependency tree it will make creating a custom lighter weight build much easier for your specific application in production.

MiamiCoder

4 years ago

Very interesting features. Like the idea of incremental release as well.

Greg

4 years ago

It looks like a big step forward, thanks Ext team!
But I’ve got two questions after reading the post:

1. When I configure mixins added to my class, what’s the role of the keys used in “mixins” object?
E.g. in this code:
mixins: {guitar: ‘Sample.ability.CanPlayGuitar’, ...}
What the “guitar” property name means? Does it mean anything? If not, why “mixins” is not an array instead, like this:
mixins: [‘Sample.ability.CanPlayGuitar’, ...]

2. having “setXxx” anf “applyXxx” methods generated - what’s the relation between them? does one of them call another one? In what order? Or maybe they are unrelated?

Alexander Hartmaier (abraxxa)

4 years ago

Great to see that a JavaScript equivalent to Moose is on the way!
Will you move that into Ext Core?

Harley

4 years ago

How are conflicting names handled for various mixins?  For example, the CanPlayDrum and CanPlayGuitar mixins both have a ‘play’ method.  If I add both of these mixins to a class, what happens when I execute the ‘play’ method?

pablo

4 years ago

@Aaron How will it make creating a custom lighter build easier if it’s a client-side feature?
As I see it, instead of loading one file the app will automatically load many files and will introduce unnecessary latency.
Frameworks are starting to use data-urls when possible to reduce the latency of loading images but here you add a latency instead of reducing it.
Wouldn’t a simple script that scans an extjs based app and generate a custom build for it be simpler and more efficient?

Arthur Kay

4 years ago

Very cool stuff! I can’t wait until the full beta is available so I can start playing with it!

One question… are mixins basically the same thing as plugins in ExtJS 3.x?

Ed Spencer

4 years ago

@pablo we’re suggesting using dynamic loading in development mode only, but still building a single application file for production use. We have a tool which builds this file for your application based on the dependency order calculated by the dynamic loader. Production speed has always been paramount to us

@Harley mixins won’t override existing methods. If a mixin function wasn’t applied you can easily get to it with this.getMixin(‘guitar’).playGuitar()

@Greg the mixin name is the for the purpose just mentioned to Harley. I think we’ll also provide a more concise way of declaring mixins

Loiane

4 years ago

Loved it!
We want more! smile

P?emek

4 years ago

What is the difference between ‘extend’ and ‘mixins’?

Alexander Hartmaier (abraxxa)

4 years ago

Will it be possible to declare required methods for mixins (roles or whatever you call them) or use them as traits (specify which should be applied at instantiation?

Alexander Hartmaier (abraxxa)

4 years ago

@P?emek: extend is interitance, mixins are ‘features’ that are added to a class.
You can read a good explanation in the Moose docs: http://search.cpan.org/~drolsky/Moose-1.21/lib/Moose/Manual/Concepts.pod#Role

P?emek

4 years ago

I feel the difference in meaning but in function, it looks the same for me. Mixins aren’t interfaces because they contains implementation. So it looks like the new class inherits from ‘extended’ class and from mixins.

stolsma

4 years ago

Very nice to see a sort of module/class loading in ExtJS 4. What I don’t understand is why Sencha didn’t follow CommonJS ‘drafts’ somewhat more and just implemented another type of module implementation…. I think a missed chance for integrating Server and Client side code…

Jay garcia

4 years ago

A complete game changer!!!

Phil

4 years ago

Looks great, I look forward to fewer lines of boiler plate code.

Jerry

4 years ago

@ed & @aaron We use the full extjs library in end consumer production on a travel website engine(http://vacations.banffinfo.com/) so we have direct experience with these load time challenges.

We noticed that we need the initial libraries loaded on the fly asap to bring up the full screen (as soon as possible) but then after the first idleness we need to bring up the rest. There is no reason to wait until they are needed. That will only cause slowness later.

Therefore, can you facilitate a custom build process where you define libraries as pre-load (needed for first ui) separate from idle-load (needed on subsequent or actions off of the first)

And finally, is this going to wrap into Sencha Touch? The great merge of all electronics is well underway—everything is getting displays with browsers—and of course nobody wants to double program and you have a great individual library for both but not combined.

Cheers,
Jerry

Ed Spencer

4 years ago

@Jerry yes on all counts - stay tuned

bigfish

4 years ago

It’s great to ‘requires’ and lazy loading of classes’ dependencies! While this is very nice for debugging, and helps reduce overall bandwidth in production, it does mean an increase in the number of requests to the server and hence potential slowness due to network latency. What would be the next logical step is to integrate this modularity into JSBuilder so that it can create a single .js file with only the code required for your app… perhaps you are already working on this ?

bigfish

4 years ago

Ah, I see that Jerry already raised this idea, and Ed answered .. nevermind smile

camelCase

4 years ago

I am considering trying to get the old ExtSharp project functioning with ExtJS 4 so I can express some portions of a new ExtJS RIA app in C# code. In the broadest terms has anything changed in ExtJS 4 to make this a non starter? I understand that my first step would be to run the ExtSharp parser over the new V4 Ext code to build equivalent C# class interfaces to the ExtJS class library.

Crysfel

4 years ago

This is amazing! I can’t wait to start playing around with the new library smile

gevik

4 years ago

It looks great. But we should not forget that the new version is basically a completely new product and probably requires a lot of digging even for advanced (component) developers. I am very happy with the new development. Thank you smile

Just a side question.. Will the documentation style stay the same? In other words, can we still use ext-doc to generate docs for ExtJS 4 stuff?

Javier Rincon

4 years ago

Great, it looks like we will need a lot of time to understand the new features. But i cant wait to start with it…

Stoober

4 years ago

I like the look of this!

In regard to the auto setters and getters for configuration items, are you including or would you consider including auto events also?

For your example of the config item “title”, an event “onChangeTitle” (and perhaps a “beforeChangeTitle” event also) would be registered and (possibly) fired by the default “setTitle” or “applyTitle” function.

This would be similar to functionality in YUI which allows all configuration items to have change events.

Isaac Peraza

4 years ago

Thank you very much to all members of ExtJs and I look forward to the release date of the beta version 4.0 of ExtJS.

My opinion of the post. I think for this new class system we perform some tests to evaluate how convenient it is to be doing many recursive calls to bring multiple files, but I think it has advantages on the other side as class inheritance and able to build a better design pattern .

If I can believe that one little step before sending the files to load, which is to validate if the class is being requested as part of the document and if it is to avoid making another call to include the requested file.

sorry for my English, but I prefer to err by not being part of this great community.

Tane Piper

4 years ago

These new features look fantastic - I just implemented my own version of the dynamic loading using require.js but ran into the issues you describe with some modules not loading in time - hopefully you’re solution will fix this.

While I understand your release cycle, is there any possibility of early access for some developers with the known caveat that some things may not work?
We’re currently holding off on some features in our build until ExtJS4 but were expecting the beta package around now based on the information released at SenchaCon. These delays will unfortunately have a major knock-on effect in re-factoring the existing code to ExtJS4 and building in some of the new features around Ext.draw and the new TreeStore stuff that we really need.

Steven Roussey

4 years ago

I have a few comments (surprise!):

1) Awesome!

2) Having looked at what other people do with mixins, you might consider the same path: dynamically change the prototype chain to include the mixin. We can discuss why this is good in some sidebar or expert discussion.

3) Packages: often in a deploy scenario, you don’t want a ext-all.js. Nor a zillion files to download situation. You want something in the middle.

-s

Ed Spencer

4 years ago

@gevik we’re working on updating the documentation generator to account for the enhanced functionality

@Stoober interesting idea, we’ll think about it

@Isaac The class loader checks to see if a class is already present so won’t reload it if it’s already on the page

@Tane coming soon

@Steven I think we have an even better solution but don’t want to place a spoiler here smile In any case, we’ll still support loading of packages

NoraBora

4 years ago

Wow, 2011 will be the year of Sencha. I expect Sencha Touch can absorb good things from ExtJS 4. Cheers~

AMp

4 years ago

how about obfuscate ExtJS?

Blacktiger

4 years ago

I was playing around with it today and wondered how to add a config option that has an empty string as the default value. It looks like the empty string is ignored and the get functions return undefined until you explicitly define one. Maybe there isn’t a good reason to do that, but I was just wondering about the design decision.

Steffen Hiller

4 years ago

Great stuff!

What about “Ext.class(‘App.LoginWindow < Ext.Window', {});"? tongue laugh

Also would like "this.apply({})" instead of "Ext.apply(this, {})"

And what about "MyApp.LoginWindow.superclass.initComponent.apply(this, arguments);"?
Can you not make that go away, like with "this.super('initComponent', arguments)" or something? Just a spontaneous idea. It could go through the base classes and call that method for every base class with the "this" scope.

But still looking forward to Ext JS 4! grin

Chinabuffet

4 years ago

Looking at some of the code, it appears that the synchronous downloads use synchronous XHR… will this require that the files being loaded are on the same domain so that it’s not interpreted as XSS?

Kevin

4 years ago

Will Ext’s modules support loading from a CommonJS module loader?

Fredric Berling

4 years ago

Great stuff !
You are doing it right.

frank

4 years ago

Nice job! Man!

boolean

4 years ago

new ideas come on, changes happening.

frank

4 years ago

For Chinese Users?please read my blog for translation:?Ext JS 4?????????????? Count down to Ext JS 4: Dynamic Loading and New Class System?

Ed Spencer

4 years ago

@frank do you have a link?

frank

4 years ago

@Ed Spencer
Sorry, just finished translation thentoo hurry post comment to paste the link. There’s the link:
http://blog.csdn.net/zhangxin09/archive/2011/01/20/6154696.aspx

hafizan

4 years ago

Are ext-bootstrap official ext4 ext.js equivilant?

Dmitriy Pashkevich

4 years ago

Great new features! Dying to see the new Data package!

Nickolay Platonov

4 years ago

@Alexander Hartmaier (abraxxa)

There is already Moose in JavaScript, its called Joose:

http://bit.ly/joose_manual

Joeri

4 years ago

Will the new class loader also be able to load stylesheets on demand, or is the “best practice” still to bundle all your styles up into one big stylesheet?

papandreou

4 years ago

While this looks like a nice initiative, I have a few suspicions based on the code samples:

1) Looks like the lazy loading scheme only applies to the ExtJS framework itself. How about lazy loading of parts of our own code? Will we have to invent yet another scheme?
2) I’m guessing the dependency graph for the framework resides in a jsb3 file somewhere. Please put them into the code itself, it’s way more flexible and maintainable.

Most of these objections have already been brought up a priori in this thread: http://www.sencha.com/forum/showthread.php?113604-ExtJS-Dependencies-(Performance-Optimizations)&p=546669#post546669

Best regards,
Papandreou

Thomas

4 years ago

Wow, it finally works just like in qooxdoo - just not as powerful raspberry

Behrang

4 years ago

Wow! Nice job!

Ed Spencer

4 years ago

@frank that’s awesome - thank you!

@papandreou fortunately, both of your suspicions are unfounded. The lazy loading scheme is easy to extend to any code using or building on the framework, including application code. If you open up the live demo you’ll see it loading non-framework code in every example.

As explained in the post and the code samples, all of the dependency graph information is found in the source code - take a look at the extends, mixins and requires declarations in the samples above and on the live demo page.

Ed Spencer

4 years ago

@Joeri currently the loader just loads JavaScript; we may extend its scope to include CSS though.

@hafizan nice to see someone digging through the code smile The bootstrap file there is a custom build purely for that example. It’s really just a subset of Ext Core and is the minimal set of code required to make the class system work

@Dmitry Data happens to be the subject of the next post – stay tuned!

James Hughes

4 years ago

“If Ext.Window were not defined when we create our class, we would get an error and our application might crash. Similarly, if the MyApp namespace is not defined we’d also get an error. These problems are both resolved with the new way to define classes”

Surely during development you WANT errors to happen?  This sort of issue should never make it into production (and if it does you should sack your testers).  Throwing errors at that point surely makes the bug easier to find, and swallowing these errors will make debugging/development harder?

Wemerson

4 years ago

really nice! Thanksss

Conor

4 years ago

@ed

As some of the previous posters had alluded to, the lazy loading is going to delay loading times due to latency etc. 

You say that “We have a tool which builds this file for your application based on the dependency order calculated by the dynamic loader.”

Few questions:

Can you clarify if this is for developers only or whether developers should be bundling it with code to clients with the release?
Will it handle app code (not just the framework)?
How are you going to deal with the various server backends (PHP, ASP, Perl, Java etc).

At the risk of sounding overly negative, but the thought of a component like a combo box lazy loading a dozen superclasses is seriously going to impact on load times!

chandru

4 years ago

You people always amaze me!!!

thanks for all your efforts.

Cheers

Westy

4 years ago

Good stuff, looking forward to the beta release!

Luis Confraria

4 years ago

This is great.

This kind of articles are just what i wanted to start with extjs4.

Please write one about the new tools and the recommended application architecture.

Thank you so much for your excellent work.

Valentin

4 years ago

Resumen en español:

ExtJS4: Las novedades

Abdel

4 years ago

Excited to see the beta version finally rolling out! I did some coding with the new class system and was wondering:

1. If I create a mixin in one class, why is its constructor of mixin not called?

2. If I apply default values to mixin variables ( thru config{} ), why are they not accessible thru getter methods?

Florian

4 years ago

Really nice stuff! I would also recommend to optimize the writing efforts. That what I see as a contraint.

I like:

- this.apply( instead of Ext.apply
- this.superclass instead of MyApp…...superclass (should be possible with this scope?)

what I would like so see the most is

Ext.define(‘MyClass < MyBaseClass, MyBaseClass2', {

Thanks for all your hard work guys! Looking forward to kickoff queued projects with the upcoming beta


Flo

David

4 years ago

Bravo!

Andrew

4 years ago

This is awesome! You guys rock. Will we be able to dig into the dynamic loader to multiplex requests for multiple classes into 1?

Donald

4 years ago

Can you guys give an example of using mixins pertaining to say an extended Ext widget…and not a generic instrument….I am not 100% following what this new “mixins” thing is and how one would use it.

Thomas Fritz

4 years ago

Very good. Great work!
Especially the Loading on demand feature is very great and will make development and optimization a lot easier!
But why did Ext not follow CommonJS “Standards” (like http://requirejs.org Loader) used by many other projects too. This would be a killer feature. This would allow for easy integration of ExtJS in existing projects, or in the future integrate other commonjs modules / packages within ExtJS! Think of it before you release ExtJS 4.0 PLEASE!! smile

Something related to that is with the restructuring of the source files and the on-demand loading of source files it would be possible and very handy to get the required object as parameter of the callback function of Ext.require - like in other CommonJS Loader. The Performance of the whole framework would be better too, because references are within the current function scope chain. This approach would also allow to not have any global Ext variable, you are rather injecting your dependencies.

PLEASE PLEASE PLEASE!!! smile

Christiaan

4 years ago

I think Arthur Kay’s question is interesting to understand mixins. I’m sure lots of developers have checked mixins out on wikipedia. At least I did.

How does plugins and mixins compare?

Jacky Nguyen

4 years ago

Just to clarify for everyone who concerns about performance / latency of the dynamic dependency loading feature:

- Dynamic loading of separate files only happen during *development* on your local machines, for ease of debugging. When you’re ready to deploy for *production*, Ext.JSBGenerator will generate the jsb file (JSBuilder manifest format) right from your live application within milliseconds, so that you can build everything into just one single .js file. You can always get the latest jsb with one click, no command line script needed.

- Ext.Loader is built to work with any namespace. When you define you own class, for example:

Ext.define(‘My.own.Panel’, {
  extend: ‘Someone.else.Panel’,

  ...
});

and that Someone.else.Panel:

Ext.define(‘Someone.else.Panel’, {
  extend: ‘Ext.Panel’,

  ...
});

Ext.Loader will load them in the correct sequence of Ext.Panel -> Someone.else.Panel -> My.own.Panel. Extending and contributing custom classes can’t be easier since you no longer need to remember what depends on / requires what. Ext.Loader takes care of everything for you. Again during production, all these non-Ext classes will also be included into one single .js file thanks to Ext.JSBGenerator.

Ed Spencer

4 years ago

@James actually, we can now throw a meaningful error. Previously, the JavaScript engine would either throw a ReferenceError, or tell you that “undefined is not a function”. Now, we can throw a meaningful error like “Ext.Window could not be found”

@Conor we have always been against dynamic loading in production. We will continue to provide a complete ext-all.js and the JSBuilder to enable developers to create their own builds easily.

Ed Spencer

4 years ago

@Donald for example, if you want to make your non-Window subclass draggable, use the Draggable mixin. If you want to enable sorting of child items, use the Sortable mixin.

@Andrew no support for that yet…

@Valentin thanks - seems to be down at the moment though

@Luis soon!

Bruno Tavares

4 years ago

Uow!!! What a coincidence, I’m using my Ext.require class since 2009 (: And it works exactly the same! hahaha

http://www.extdesenv.com.br/en/tutoriais-estudos/carregar-codigo-ext-sob-demanda/

Thanks god this funcionality was added to the core!

Steffen Hiller

4 years ago

What about my 3 suggestions about reducing code and complexity? Not so good? :-|

Ed Spencer

4 years ago

@Steffen I’ll think about adding this.apply… it’s kind of redundant but a few people have asked for it

Not such a fan of the alternative syntax though

Jacky Nguyen

4 years ago

@Steffen Hiller: We have them implemented, just not mentioned in the blog post as we wanted to keep it short & concise. We’ll slowly reveal everything when Ext JS 4 is closer to release wink

christiaan

4 years ago

@Ed Spencer, if you’ve have always been against dynamic loading in production. And I asume thats partly because it’s a good thing to minimize the number of http request. Then I hope you have or will apply the same reasoning to loading images. That means natively support the use of a sprite for all icons of buttons, tabs, panels, windows without showing the adjacent images in the sprite. Do or will you in 4.0?

Steffen Hiller

4 years ago

That sounds goood! grin

Jamie Avins

4 years ago

@ christiaan

Stay tuned for more on the extensive use of sprites in 4.0.

Valentin

4 years ago

@Ed
it’s already running smile

Nikolay

4 years ago

Great, thanks for all!

We’re waiting for the release of Ext 4.

Thomas Fritz

4 years ago

@Jacky Nguyen: I understand that this is only for development and every namespace could be used. But why not compatible with CommonJS. ExtJS would benefit from other tools outside and could be used together with other tools and vice versa. What about existing sources developed as CommonJS Modules. In such a case you would have again at least 2 different Loaders and you can not optimize them together.

Besides that, does Sencha has any Ticketing System where ExtJS Users can create tickets and so on. That would make it easier to ExtJS Users to see what is planned, what will change in the next versions and could post their wishes and feedback and then we could see when it is in a release. Others could vote too on a ticket. Then you would not get hundres of posts in the blog and forums with questions about ExtJS4 when you post some details in here.

Thomas Fritz

4 years ago

Do not get my previous comment wrong. I am ExtJS user since yui-ext and every company i worked so far since yui-ext is using ExtJS now because i convinced them to use it.
I really like the effort in ExtJS 4.0 with Sass, dynamic Loading, the Plugin System, etc.. Great work. Great Software. Great Company!

But one weakness in my opinion is Senchas Communication with their customers/users about features, planned features, feedback and so on. I mean there is only a very minimalistic Roadmap. Dynamic Loading, Mixins is not on this list for example. Almost every Software Company has a Ticketing System for example where every user can create, comment and vote for tickets and with information about milestones and what tickets/Features are planned for what milestone.
The point is that as a developer you have to know what feature will make it into the core of a software and when. If some feature will never be integrated into a software you have to create it for yourself - which is time consuming and therefore expensive. But when i know that a feature will be in the release i am not going to implement it for my own - i would search for a story or ticket and give feedback about that planned feature, try to help and wait for the next release and use that part in the core. But that is only possible when we all know where to ask, where to look and where to give feedback. I know there are the forums but thats not the same. A forum gives not the same information.

Kind regards

phil

4 years ago

in this example, js loading use a disable caching feature.
i hope (and i suppose) that it will be a way to allow script caching ?

Tim Toady

4 years ago

I am really liking this.  You guys are moving in the right direction.  I can definitely see Ext growing in popularity with the improvements you keep bringing.

Is the only issue against lazy loading in production latency?  The time it takes to load a script dynamically is shorter than the traditional web site pulling a new page. I understand having all the core features loaded up front, but in an application with large sections of code that might not even be used, doesn’t it make sense to load them dynamically in as few requests as possible?  (I’m not trying to argue. Just trying to learn)

Les

4 years ago

Looks like release 4 will be a winner smile

One thing that bothers me when debugging Ext applications is that it’s not easy to tell what class was used to create a particular instance.

If I define a class Ext.define(‘Sample.Musician’, {..., I’d like to see a property in Firebug that would show e.g declaredClass: ‘Sample.Musician’.

Ed Spencer

4 years ago

@phil - yep - the cache buster is optional and is mainly there to make sure the browser doesn’t cache incorrectly when in development mode.

@Tim that’s right - the dynamic loading is aimed at making development easier, once in production we still recommend rolling all of your application code into a single file to load it all at once

@Les it’s a lot easier now as the stack trace tells you which file caused the error instead of always showing some line in ext-all-debug.js

Les

4 years ago

For the sake of consistency and to make the code shorter) “requires:” should be just “require:” in the example below.

Ext.define(‘Ext.Window’, {
  extend: ‘Ext.Panel’,
  requires: [‘Ext.util.MixedCollection’],
  mixins: {
      draggable: ‘Ext.util.Draggable’
  }
});

Les

4 years ago

Also, I’m curious why mixins is an object while require is an array.

Ext.define(‘Ext.Window’, {
extend: ‘Ext.Panel’,
requires: [‘Ext.util.MixedCollection’],
mixins: {
draggable: ‘Ext.util.Draggable’
}
});

Ed Spencer

4 years ago

@Les actually, I would have preferred to pluralize ‘extend’ into ‘extends’ but extends is a reserved word in JavaScript.

The ‘requires’ declaration can also take a string if you only require a single class. We usually offer this shortcut when passing arrays to various parts of the framework as it reads better if not forced into a single item array

Kevin Cho

4 years ago

I really liked the data package improvements but this one I’m slightly puzzled.  I do see that new way of creating new Class can reduce errors but at the same time..it’s really not.  If I truly don’t have the class I’m extending from… I rather see the error then covering up for later.  Also, mixins sounds like plugin as well.. In any case, I will play w/ these features when it arrives! Perhaps there are other hidden advantages I’m not seeing here.

Nicolas BUI

4 years ago

Hi,

I was sure that you will go to this direction after dissecting Sencha Touch source code few month ago.

While Ext.define(‘namespace.MyClass’ ...); is nice, there are although some little annoying caveats for IDE users out there.

They will lost the most important part of the completions features from their favorite IDE, don’t they ?

The only IDE that parform well is WebStorm (the best out there for JavaScript), but Eclipse won’t be able to guess that namespace.MyClass exists.

Ed Spencer

4 years ago

@Kevin it actually enables us to give slightly better errors in those cases. It’s really hard for a lot of newcomers to the framework when they see an “undefined is not a function” error caused by a bad Ext.extend call.

Aside from the other benefits of a stronger class model, the string-based approach lets us generate those nicer error messages.

ken

4 years ago

Lots of programmers complain about the bulk of extjs. Great that it is hosted on a CDN but at 1Mbps, an ~600KB ext-all.js takes ~5sec to download at 1Mbps.

Khebs

4 years ago

I never thought that the design i made for so long, is the same model as ext is in now.. although, im using Package name space, but same pattern in creating class..

Package(‘MyApp.ui.MDI’, {
  extends: ‘MyApp.ui’,
  initialize: function() {
      ...
  }
});

This is great! Also, i have my own mvc, can i still use ExtJS4 w/ it?

Phil_G

4 years ago

I have the same question as Pablo, but I haven’t seen any discussion on it yet:

Pablo said: “Is there a standard for naming my own configuration options?
For example, if I’m extending Ext.Panel and adding subtitle:‘something’ I can’t know for sure that Ext won’t add a config option with the same name in the future.”

I’d like to echo this concern.  There needs to be a clear separation between Ext-specific config options and my class’s methods and properties.  Something like the following is absolutely necessary to prevent conflicts and make the class system more robust:

Ext.Define( ‘Programmer’, {
  //Ext config options go here
  extend: ‘Person’,
  requires: [‘Blah.blah.Blah’]
}, {
  //methods and properties that get added to my class’s prototype go here
  eyeColor: ‘green’,
  hack: function() {}
} );

Jevgeni

4 years ago

You’re done a great work! I love ExtJS and already bought a pre-sale license! Waiting for stable release impatiently.

Rob Callahan

4 years ago

I’ve been using ExtJS since 0.9 and I’ve always thought it was the best. I don’t know why folks continue to use libraries like JQuery, etc. when Ext has so much to offer. Thanks guys for your continued efforts. You guys rock!

lovesl

4 years ago

Great !!  Mixins is very good

Russ Jackson

3 years ago

Hi, first of all - very exciting.  If this works as advertised it will alleviate a big headache we sometimes encounter.

What are the bare minimum script files needed to get the dynamic loading working?  For example, what script tags would need to be included in order to get the Ext.require(‘Ext.Window’, ... example above working?

I tried to experiment with the BarRenderer.html example and replaced the bootstrap.js script tag with an ext-core.debug.js script tag (thus causing ext-all-debug.js to be omitted).  However, the chart does not appear in this case and via firebug I don’t see any chart classes being loaded, as defined at the top of BarRenderer.js:

Ext.require(‘Ext.chart.*’);

Can you please explain? 

TIA

Russ Jackson

3 years ago

I did some more investigating on the above and discovered that the Loader class is included in ext-core-debug.js and that it needs to be enabled as described in the code/help, i.e include the following after loading ext-core:

  [removed]
      Ext.Loader.setConfig({
        enabled: true,
        paths : {
          ‘Ext’ : ‘../common/src’ // provide your own path to the Ext source files here
        }
      });     
  [removed]

However, enabling dynamic loading seems to have exposed several problems with the BarRenderer example and/or dynamic loading itself:

(1)  The loader did not like the Ext.Window alias used on line 2 of BarRenderer.js;  I changed it to: Ext.require([‘Ext.window.Window’ ...

(2)  Had to add Ext.data.JsonStore to the requires list on line 1 of example-data.js

(3)  Once the above were resolved I received the following error:

[Ext.ClassManager] Cannot create an instance of unrecognized alias: widget.chart

Seems that perhaps there are some issues with dynamic loading or at least the charting API that need to be worked out?

yiyu jia

3 years ago

I have a question. if all classes are referenced by their string name as using Ext.define() instead of Ext.extend. Wont this be challenge for IDE editor vendor to implemented syntax highlighter? If defined class name is not highlighted or it can not be auto completed. Wont it cause more typo?

Or, my question is, is there anybody here know a IDE editor which might support syntax highlight and code auto complete for class defined by Ext.define? Or, I will just carefully copy and paste to avoid typo?

Swarnendu De

3 years ago

Its awesome. Liked the new class loading functionality and the default architecture. And providing the dynamic loading feature I think the best approach regarding ExtJS. I used to work with creating my own class loader for dynamically loading javascript files. This new Ext Loader will help a lot. Hope to see few examples using newest functionality of ExtJS 4.

Josh Ohio

3 years ago

camon, dojo had mixins for so long its not funny, its about time ExtJS caught up to dojo’s class system. What about dojo’s templating system? anytime soon?

Raul Csj

3 years ago

Wow! Great work! Dynamic Loading!!!!!!

samgfrias

3 years ago

great work! tnks smile

Ajsie

3 years ago

Loading one file to the client and then realizing it has dependencies that need to be fetched is bad for the users that have to wait for multiple HTTP requests when it all should have been loaded with one request.

A suggestion is to look at how YUI solved this with YLS.

http://reid.github.com/decks/2011/bayjax/yls.html

In short its running a node.js server on that will calculate the dependencies when it receives a HTTP request and will load all files into the client.

Can’t ExtJS do the same in the future? Then dynamic loading won’t be just for development but for production too!

Ebru

3 years ago

Hi,
I need a help:( I want to access json data with ExtJs 4 but I can not do this.I can access json with Extjs 3 use Ext.data.JsonStore and I look the document of Ext 4 and I see there is not Ext.data.JsonStore ….HOW I ACCESS JSON DATA WITH EXTJS 4(?)
Please HELP….
Thanks…..

Bipin

3 years ago

@Ed The LoaderDemo doesn’t seems to be working when I changed ext-bootstrap-debug.js in your index.html to ext-all-debug.js or bootstrap.js from latest ext-4.0.2a. I was running this off a web server.
Changing ext-bootstrap-debug.js made the src/* files inaccessible, as it started finding those file from the same location as index.html. And I didn’t see the Ext.Loader.basePath mentioned in EXT JS 4 documentation.

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

Commenting is not available in this channel entry.