ClearDataBuilder for Ext JS 4.1

ClearDataBuilder for Ext JS 4.1 has arrived! The URL for Eclipse plugin update is

What Has Changed
In addition to Ext JS 4.1 support, we introduce much simplified project wizard. Prior versions of CDB required you to create a generic Dynamic Web Project with CDB-specific facets. Now you explicitly create ClearDataBuilder ExtJS Project:

From here you have a clear choice: create a brand new project or piggy-back on one of the pre-built example ones:

The wizard will present you just one dialog. That dialog will contain all settings your project needs.
Let’s look at each of the project types one by one.

Java Example Project

This is the simplest project to setup and the dialog contains only two settings, which are required by all project types: Ext JS Location and Target Runtime.

The first one lets you choose between embedding Ext JS inside your app or point to an external Ext JS URL. To embed Ext JS you select “Browse…” and navigate to Ext JS location on your hard drive. Alternatively you may point to a local URL on your own server or to a Sencha CDN. In the latter case you will be constrained to use production version of the Ext JS.

With the second setting you are indicating a deployment server. Keep in mind, though, that we do not do any testing beyond Tomcat:

The rest – deployment of the example sources is done automatically.

MyBatis and Hibernate Example Projects

If you select MyBatis or Hibernate Example project, you will have to provide one additional setting: location of the folder where wizard deploys the HSQLDB database cleardb that is used by the example application. Keep in mind that you will have to explicitly start the database:

Non Example Project

For regular projects you will have to select the persistence type: MyBatis, Hibernate or None.
You will be able to optionally include Spring support, unless you use MyBatis persistance: we plug MyBatis via Spring so here you do not have a choice. Finally, you will need to select a connection:

That’s it for now. I will be presenting the Ext JS 4.1 and CDB for ExtJS on the Fifth Annual Farata’s Symposium, so join us there.


Using WebJars for Assets Management in JavaScript Projects

Using automatic build tools for dependency management is best practice in Java world and usage of tools such as Maven has been proven by the years.

But can we utilize existing Maven knowledge of Java dependencies management for JavaScript projects. Luckily, some Java and JVM frameworks (like Grails or Play2) provided their own way of dealing with static resources.

But in most common situations, you don’t have lots of options for deploying your application:

  • keep framework artifacts inside war (minified or not). Not very convenient option if you have lot of small assets in like in Ext JS.
  • use library from CDN (common purposes, like Google or Yandex, or vendor-provided, like Sencha’s Ext JS CDN). Also not very convenient b/s you need to have persistent internet connection during development process.
  • use webJars

Wait, but what is webJars? A couple weeks ago James Ward announced a webJars project to help manage JavaScript dependencies into Java projects. He created maven repository and included few popular libraries (jQuery, Backbone.js, Twitter Bootstrap).

Also he created sample spring mvc application to demonstrate how to use this webjars in real project.

If you can’t find library what you using in repository you can submit new webjar request via Github Issue Tracker.

Today I submitted request for adding Ext JS webjar. Also I provided use case and POC based on James’s spring app demo. You can find that Ext JS webJar usage with spring web app in extjs branch of repository.

The idea behind the scenes if pretty obvious – Spring MVC maps the requests from a given URL to files in the classpath (inside jar). Simple, isn’t it?

Besides, some IDE’s (like Intellij IDEA) can recognize js libraries even inside jar file. But again, for development purposes you can still have copy of framework inside of your project workspace. At this point, you must exclude from ready for deployment artifacts somehow, e.g. using build script. Also, one of benefits of webJars approach – you can maintain different sets of artifacts – debug, release, minified and etc – using maven dependency scope.

Please go to the mentioned github projects, fork it, play around, and share your thought in comments below, and let me know what you think about it!.

If you’re looking for a JavaScript and Ext JS training, please visit our Web site for up-to-date information about the scheduled classes. By the way, two days Ext JS workshop is coming up

Viktor Gamov

How and Why use Overrides in Ext JS Framework

Ext JS is a powerful HTML5 framework that allows you to get things done in a robust and maintainable way. It does a great job fulfilling your needs for the client-side development on the web. However, you may sometimes come across non-trivial use-cases, for example, fixing issues within the framework itself. There is no such thing as a perfect framework. Bug happens, but what I like about Ext JS is that if you’ll run into a bug, you don’t need to wait for the framework creators to schedule, create, test, and release a fix. You can do it yourself, and in this blog I’ll talk about an important overriding mechanism that exists in Ext JS.

To override a class method in object-oriented languages like Java, you start with declaring a subclass of another class. The flexibility of the prototype-based languages like JavaScript allows you to override the method of the existing classes. Ext JS goes one step further by adding a convenient mechanism of overrides known as Ext.override and starting from Ext JS 4 with the configuration property overrides.

A Short Recap of Ext JS Overrides
Let’s consider the following real-life example. While debugging I find it handy to write the log records to know when my controllers are initialized. Instead of adding console.log() into the constructor or init of each controller I use overrides. Here is how I prescribe Ext JS to override the behavior of the standard Controller class using new Ext JS 4 overriding mechanism –Ext.Class.override configuration:

Ext.override(, {
   init: function() {
        console.log(this.self.getName() + ' created');

Both versions have the same effect – they override the init method. (As any prototype-based overriding they affect even existing instances of the classes, although in case of init() method this is not relevant.) I recommend you use the first technique as it’s more compact, readable, and most importantly – safe, since override:'' ensures that class is loaded by the time the override is executed.

In the classical object model you must inherit a class to override its methods, so these overrides might look weird at first glance. The internal implementation is dead simple – the function declaration gets replaced. The existing declaration is preserved in an internal variable, and you get access to it via this.callOverriden().

Managing Overrides In Your Project

As your project grows there are more and more overrides to manage and deploy in production. Prior to the introduction of Ext.Loader it was popular to combine all overrides into a single file, say overrides.js that you would reference in the index.html right after ext.js. However, this approach had several drawbacks:

  1. It’s hard to navigate between the overrides located in the single file
  2. The <script> tag doesn’t guarantee the order of scripts loading. So, you can face the problem when your application is loaded and started, and only after that your overrides will come into play.

A better approach is to explicitly load your overrides by Ext.Loader. This allows to keep them in the nice folder structure and to control the order of execution. I like my overrides to mirror the folder structure of the patched Ext JS sources. For instance, an override of will be in the, while an override of will be in the etc.

Let’s continue with overriding the Controller. Here is the modified version:

 Ext.define('', {
    override: '',

    init: function() {
        console.log(this.self.getName() + ' created');

Assuming that App.controller.Main is my application specific controller, below is the application that pre-loads the patch. All I need to force the patch pre-load is requires: ['']. The patch will be loaded before application is instantiated, therefore before any controller, view, or store is created:

Ext.Loader.setConfig({ enabled: true });

    requires: [''],
    name: 'App',
    controllers: ['Main']

Combining and Versioning The Overrides

What do you do with multiple patches? Simply make the “root” patch that requires all others. Here is an example:App.path.ExtJSPatch:

Ext.define('App.patch.ExtJSPatch', {
    requires: [
        // ...Other overrides

Whether you are extending ExtJS or fixing the bugs, you should revise your overrides with each new Ext JS release. To reflect the version of Ext JS that your overrides are relevant for, I suggest embedding the name of the version into the name of the “root” patch and maintaining different ones, per ExtJS version:

    requires: ['App.patch.ExtJS407Patch'],

Hope you’ll find this blog helpful!

To learn more about the proper way of architecting enterprise applications attend our 2 day Ext JS workshop in June in New York City. Enter Anton as a promo code to get $100 off the price.

Anton Moiseev

Avoiding Duplicate Suffixes in Ext JS MVC

One of the most appealing features of Ext JS 4 is the fact that it has all you need to develop your application using the MVC architecture. You don’t need to add any third party MVC framework to your Ext JS application. In your controllers, that you attach to the application, you simply declare the class names for your store and a view. In return, Ext JS generates the controller’s getter methods to access the store and view instances and also allows controllers to intercept events that may happen anywhere inside the views. You are not forced to use MVC, but since it is convenient and does not cost much. I just finished preparing a 100% MVC sample for the upcoming release of the Ext JS version of our Clear Data Builder code generator.

Convention over configuration is the only price you pay for implementing MVC in your application. Just follow the strict folder names – controller, view, store, model. It’s not too expensive, is it? In fact, I like it.

That said, dare you to name a store class as Ext leaves you one on one with eyebrow-raising controller code like this.getCustomerStoreStore(). In other words, Ext is appending the Store suffix for stores, Model for models and so on, softly suggesting that you should stay away from using your own suffixes.

Now, if you are anything like me, you get an instant acid reflux at multiple classes with the same core name like MyApp.model.x.y.z.Customer,, and, perhaps, MyApp.controller.x.y.z.Customer and others, especially when you jump between them in one editor. Do not worry – all you need to treat the “condition” is to override the createGetters method of the before your application starts, for instance – this way:

    enabled: true

    function () {{
            createGetters: function(type, refs) {
                type = Ext.String.capitalize(type);
                Ext.Array.each(refs, function(ref) {
                    var fn = 'get',
                          parts = ref.split('.'),

                    // Handle namespaced class names. E.g. feed.Add becomes getFeedAddView etc.
                    Ext.Array.each(parts, function(part) {
                        fn += Ext.String.capitalize(part);
                    // --- Prevent StoreStore-like suffixes --- 
                    pos = fn.length - type.length;
                    if (pos<=0 || fn.substring(pos)!==type) {          
                        fn += type;
                    if (!this[fn]) {
                        this[fn] = Ext.Function.pass(this['get' + type], [ref], this);
                    // Execute it right away
            // --- Start your application when done 
                name: 'MyApp',
                controllers: [

To learn more about the proper way of architecting enterprise applications attend our 2 day Flex-to-ExtJs workshop on April 19-20, 2012. Enter Victor as a promo code to get $100 off the price.


UPDATE: See our post Why and How to use Ext JS Overrides that illustrates the most elegant Ext JS overriding technique.