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!

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?

  [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?

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

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() {}
} );

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?

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

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.

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

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

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

@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

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’.

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)

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

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.

We’re waiting for the release of Ext 4.

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

Not such a fan of the alternative syntax though

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

Thanks god this funcionality was added to the core!

@Andrew no support for that yet…

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

@Luis soon!

@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.

- 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.

How does plugins and mixins compare?

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!!!

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

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?

ExtJS4: Las novedades

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.

thanks for all your efforts.

Cheers

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!

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?

@hafizan nice to see someone digging through the code 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!

@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.

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

There is already Moose in JavaScript, its called Joose:

http://bit.ly/joose_manual

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

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!

@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 In any case, we’ll still support loading of packages

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

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.

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.

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.

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?

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

@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

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