Goodbye Sencha, Hello Google

Posted on in GCP Sencha

Within 4 years working for Sencha, I’ve done 86 trips. 28 live trainings, I spoke at 38 webinars and events (including SenchaCon, FITC and O’Reilly). I’ve visited 15 countries and I’ve attended 3 SenchaCons. I’ve spoken with many customers. I’ve worked with every public, EA and beta version since Sencha Touch 0.8, and Ext JS 4.1. I’ve created many applications like []( and [](
also I wrote a book about Sencha Touch for O’Reilly: [–Sencha-Touch-Real-World-Approach](–Sencha-Touch-Real-World-Approach).

However, all good things come to an end. I’ve decided to start a new challenge within my career. It’s a bit bittersweet. When I started working for Sencha, I was already a huge fan of their technology, I still am and also will be in the future. Although I won’t be working for the company anymore, I am still very excited in seeing what the future will bring for Sencha. With their new line-up of tools (Sencha’s Visual Studio Code plugin FTW!), NodeJS-based build tools and the new modern class system, I think the future is bright for Sencha wftdhfp.

Last week, was my last week at Sencha.
From next year, I will be start working as a sales engineer for Google. The project were I will be working on won’t be anything competing to Ext JS. Instead, I will join the Google Cloud Platform team. It’s a role, where I still will be in contact with many developers but in a broader sense than just front-end or JavaScript.
It might be even, that we will be still in contact with each other. Where I can help you in how you can deploy your (enterprise) applications into the cloud, and which services can help you by developing software faster. In case you’re interested; have a look: [](; GCP currently has a deal, where you can get 300 dollar for free, to spend on the Google Cloud Platform.
(For what’s worth, my blog is actually hosted on Google’s Compute Engine, where I have the full control over my virtual machine in the cloud, and I can easily scale and maintain.)

What’s up with this website? Will I still write blog posts? Yeah I will. Honestly, I’ve created this blog in 2005, mainly for myself, to help me remembering dev problems I’ve faced while developing in Java, PHP, Salesforce, JavaScript, HTML, Sass/CSS, Python, Django and later on; Sencha technologies. As working on a daily basis with the Sencha Tools and frameworks, and meeting with so many customers; I’ve always known what people like to read about, and I am still planning in doing so.

As it was always a dream for me to work for Sencha Inc. it was also always a dream for me, to work as an engineer for Google. I’m the living proof, that we can all make our dreams come true. As long as you’re a good person and eager to learn something new.

Sencha & ECMAScript 2015

Posted on in ES2015 JavaScript

With just a few more days to go, before the release of Ext JS 6.2, (BTW, Can’t wait! Material Design theme, pinch to zoom, D3 integration, calendar component and much more…) Sencha is already busy with working on the next major version of Ext JS.

We will give you a preview on our long term roadmap on:


One of the things that’s gonna be huge, is ES2015 support for Ext JS. Our goal is not to rewrite the whole framework according the new ECMAScript standard. no. ..but we want you to be able to write ES2015 code together with your Sencha framework API calls. So you can leverage the advantages of cleaner JavaScript code in your own Sencha classes and controllers.
With that comes new tooling that includes a transpiler, to make sure your code runs in all the supported browsers, and probably will also support for TypeScript, Grunt/Gulp etc. It’s all at an early stage yet, but if you have questions, (and you’re in Europe the week of the 20th of September), you will have the chance to meet the Sencha product manager and engineers at the roadshows.

I will be there as well, presenting an ECMAScript 2015 masterclass. I will cover the top 10 new features of ECMAScript 2015, and teach you what’s new through code examples.

(Are you from the USA? - I will give the presentation at SenchaCon in Las Vegas, November this year.)

Think about:
Block Code Constructs, Arrow functions, Default Parameters, Promises (see also my earlier post:, Classes, Modules... etc.

But there’s much more. And unfortunately not everything fits in my Top 10 / in an 45min talk. I like to share with you some more ES2015 code snippets, which are as cool, but didn’t make it in my final presentation. Have a look, this article contains info about:

  • Spread Operators
  • Maps & Sets
  • For Of Loops
  • Generators

Rest parameters & Spread Operator

Let’s say I have a function but I don’t know how many arguments I am gonna pass into it. Maybe 1, maybe 2, or maybe 15. (Not sure if you would want that tho... but you get the idea).

The spread operator looks like this: ...n. 3 dots and a variable which holds an array. That array contains all the parameters that you passed in. The rest parameters.
Let’s have a look how we did this before ES2015 and what’s new:

You can see the ES2015 is much nicer to write. It’s better performing, and it returns a true Array, where the old fashioned JavaScript arguments just contains an object that somehow fakes to be an Array.

You can use the spread operator in combination with Arrays for example:

These new data structures are supported in most of the modern desktop browsers.

New Data Structures

Map & WeakMap

The following four data structures are new in ECMAScript 2015: Map, WeakMap, Set and WeakSet. Let me explain how these work.

Maps are a store for key / value pairs. The Key and value could be a primitives or object references.

ES5 JavaScript was missing a data structure for mapping values. What people use to do; was abusing objects to save values, and that can lead you into nasty inheritance pitfalls. (See:

Maps give you a whole bunch of extra functionalities. You can get and set values in a map. You can delete a value in a map. You can loop through entries or values in maps, and you can clear them:

A WeakMap is a map that doesn’t prevent its keys from being garbage-collected, so you don’t have to worry about memory leaks.

It has almost the same functionalities as a Map, however you can’t iterate over the keys, values or entries and you also can not clear it.

Keys of WeakMaps are of the type Object only. Primitive data types as keys are not allowed (So a String, Number, Boolean, null, undefined or a ES2015 Symbols can not be used as a Weakmap key.). A Map can use primitive values for keys.

w = new Map; 
w.set('a', 'b'); //Map { a: "b" }

w = new WeakMap; 
w.set('a', 'b'); //TypeError: "a" is not a non-null object

Sets and WeakSets

Sets are collections for unique values. The values could be also a primitives or object references.

An ES2015 Set has similar functionalities as a Map. But a value in the Set may only occur once; it is unique in the Set's collection and can not contain duplicates:

var myset = new Set(["A", "A", "B"]);
console.log(myset.size); //2 !!!

Like a WeakMap, WeakSet is a Set that doesn’t prevent its values from being garbage-collected. It has simpler API than WeakMap, because has only three methods:
add(), delete() and has().

These new data structures are supported in most of the modern desktop and mobile browsers.

If you want to use it in production, you will need to make use of a transpiler like Babel, who can provide you a polyfill. (

For-of loop

The for...of statement creates a loop iterating over iterable objects (including Array, Map, Set,String, arguments object etc..):

It is the most concise, direct syntax yet for looping through array elements and it avoids all the pitfalls of for–in loops, (which you would typically use for looping over object properties).Unlike forEach(), it works with break, continue, and return.

As you can see it is pretty similar to for-in loop, which can be used to iterate through object properties.

These new data structures are supported in most of the modern desktop browsers.


Generators are simply subtypes of Iterators. They are a special kind of function that can be suspended and resumed, which is different compared to iterators.

Generators use function* and yield operators:

Note the yield statements. It returns a generator instance and moves to the next yield when next() is called.

The snippet for the Dice Generator has a while loop that won’t end. It can roll numbers between 1 and 6.

These new data structures are supported in most of the modern desktop browsers.

If you want to use it in production, you will need to make use of a transpiler like Babel, who can provide you a polyfill. (

Want to learn more about ECMAScript 2015? Join me at the roadshows:
Beside ECMAScript 2015 and TypeScript fun, there will be much to talk about: How to Test your JavaScript code, Build Data analysing apps with Ext JS 6.2, new upcoming Sencha Tools, customer cases and much more...

Tutorial: Full-stack JavaScript for the Enterprise. Getting started with: Ext JS, Node.js, Express, MongoDB and Docker. (5)

Posted on in Docker Environment Ext JS 6 MongoDB Node JS NoSQL

This is part V of the tutorial, and covers how the Ext JS client app can consume the server Node.js API

Let the Ext JS app consume your API

By now we have a working back-end with Node, and a working front-end with Sencha.
Now we are ready to modify our Sencha app, so we can consume our back-end data and see it all in action!

It’s a simple client application with CRUD functionality for the Users model. With other words, we can create (POST) new users, read users and user details (GET), update existing users (PUT), and remove a user (DELETE).

I’ve added the codebase to Github, so let’s go through it, file by file. We will focus on the Classic Desktop view first, later we will create a mobile phone view.


The application doesn’t auto create a viewport. Instead I’ve created a custom launch function, which either creates a login view (with the viewport plugin enabled), or the main interface with the viewport plugin enabled. It depends on the authorization token, if you have one on the device, it will auto login.

Take a look into the following files:

Here you can see the login panel. It’s actually a non-closable, non-draggable window, locked in the middle of the screen. The user can enter the username and password, which will be posted to the Node Express server. In case the username and password match with what’s in the database, it will return a token. In the success callback, we will save the token to the browser local storage.

Notice that we created two ViewControllers. One which will be shared by the classic and modern view. (This one contains the functionality to communicate with the back-end, since that’s view irrelevant.) The other ViewController, extends from the shared VC. This is the VC that contains an alias, and is bound to the classic view.

Note that although we Bcrypt the passwords in the database. It’s not secure to send passwords over HTTP. An attacker could very easily sniff the username and password that will be in the POST. Therefore enter: You could very easily create a free SSL certificate. You can find a guide here: so you could set this up in no time.
It’s actually very easy, as long as you have console access to your webserver.

Let's dive further into our Ext JS code:

That’s the main viewport. It’s pretty much the same as the generated one from Sencha Cmd. We’ve just added a logout button. (which will destroy the main viewport, and remove the token from the localstorage.)

This is just a view with a grid. It shows a grid column for the first_name, last_name, email and an action column to remove the user from the grid. The functionality for this can be found in:

onRemove makes an AJAX call with the DELETE method, it makes a call to a URL that contains a user id.

When you click on a row in the grid, it will open a popup window, which contains the form.
I’ve implemented a renderConfig, which will hold the selected record. That way, as soon as the window will be created, and you run setRecord() on the form, it will run updateRecord() and load the record in the form, since the model fields map the form fields.

When you submit the form, you will get into the beforeSubmit() method. Here we just determine if the form contains a hidden form field, which contains the user URL. If it does, it means, the form contains data, so every change made will be a PUT request. If the form is empty, we will add a new user, and therefore we POST to the /users overview URL. The AJAX request itself, can be found in the shared user VC.

And that’s it for the desktop view.



The mobile view re-uses most of the functionality that’s already there. What is new, are the mobile (phone) views:

If there’s a token available, it will add the main view to the viewport, else it adds a login view.

The login view is a container, which centers a login form in the middle of the screen.
It calls the login view controller, for the onLogin() method. This method uses the doLogin() method from the shared login view controller, which contains the AJAX POST call, to request a token. Once logged in, it will add the token to the local storage, and it will remove the login view from the viewport, and instead add the main view to the viewport.

The main view is just a tabpanel, with for now, just one tab. It contains a hidden back button, which will be enabled once you are in a form. And it contains a logout button, which calls the onLogout() method, which removes the token, and resets the views.
It contains a user tab, which has a card layout. It can switch between a grid view which list all the users, or a form, to edit one user.

This is the list view. It contains an itemTpl with the first_name, last_name, email, username and password. Once you tap an item, it slides in the userform.

This form contains also a toolbar with a Delete button. This toolbar will be hidden, when you open the form via the Add button. But when you tap an item, it’s visible, and the form will be prefilled with data. It contains similar functionality as in the classic toolkit. It holds a config with the record.
updateRecord() will be called, every time when you run setRecord().

Feel free to download the code base and play around with it.


By the end of this part of the tutorial, you will understand how the Sencha Ext JS client can consume the Node.js server API. In the next blog posts we will focus on getting familiar with Docker.

Read the next part

Tutorial: Full-stack JavaScript for the Enterprise. Getting started with: Ext JS, Node.js, Express, MongoDB and Docker. (1)

Posted on in Docker Ext JS 6 JavaScript Node JS

This is part I of the tutorial, and covers: JavaScript on the client.

Yeah you are correct, when you have a web project, optimized for production, you can use FTP and simple upload the folder on your server. That’s easy, and when you only have a simple HTML5/JS/CSS app, or an application with a PHP back-end on Apache this probably works fine for you. But what, if you have a very complex application, or you are working on an application with a large team? You probably want to automate as much as possible, and make every live build easy.

This tutorial will show you, how you can create an app where we will use JavaScript on the client (an Ext JS 6 app), and JavaScript on the server (Node.js with Express). Maybe you have played around with Node.js before. When you configured a Node.js app with Express etc, you will probably need to install packages via the the NPM packages manager. These are all dependencies. Now imagine you’ve created on your local workstation a fully working back-end, with Node.js and a MongoDB database. You had to install a lot of packages, and make some configurations on your system. This can be a configuration where you save environment passwords, or maybe even hardware configurations.
What you don’t want, is to manually replicate all the settings and configurations you made locally, again on the server. Ideally, you will take whatever you have on your local machine, and take that over. Maybe you even want to run the same operating system and hardware on production. This is where Docker comes into play.

With Docker you can create an isolated container with all the files such as dependencies and binaries for your app to run, making it easier to ship and deploy. It simplifies the packaging, distribution, installation and execution of (complex) applications.
So, what is an isolated container? These containers are self-contained, preconfigured packages that a user can fetch and run with just a single command via the Docker hub (like Github, but for Docker). By keeping different software components separated in containers they can also be easily updated or removed without influencing each other.

About Docker

With Docker you can create an isolated container with all the files such as dependencies and binaries for your app to run, making it easier to ship and deploy. It simplifies the packaging, distribution, installation and execution of (complex) applications.
So, what is an isolated container? These containers are self-contained, preconfigured packages that a user can fetch and run with just a single command via the Docker hub (like Github, but for Docker). By keeping different software components separated in containers they can also be easily updated or removed without influencing each other.

What you will need:

For this tutorial I used: Ext JS 6 and Cmd 6.0.2, Node.js 5.8 with NPM installed and Docker 1.10.

Please install the following:

Ext JS 6: Create the client app

Create the following folder somewhere on your hard drive: dockerextnode.

Put a temporary copy of the Sencha SDK inside dockerextnode, (for example ext-6.0.2). If you don’t have Ext JS yet, feel free to download the trial:

Open Windows Command / Terminal, and navigate on the command-line to the dockerextnode folder. From there enter the following commands:

$ mkdir server
$ cd ext-6.0.2
$ sencha generate app Client ../client

You’ve now created 2 folders. The server* folder, which will contain the Node code later and the **client folder, which contains the copy of the Sencha SDK together with a demo app.

Let’s remove the temp folder:

$ cd ..
$ rm -Rf ext-6.0.2

You’ve now removed the temp. Sencha SDK folder. We can now, start testing our Sencha demo app:

$ cd client
$ sencha app build production
$ sencha app watch

This command will spin off, a Jetty server on Visit this page in the browser, and confirm you see the Sencha demo app. Once, you’ve seen the demo app, we can stop the server, by stopping the sencha app watch (with CTRL + C for example). We will keep the demo app like it is, but this could be a nice starting point for you, when you want to create your own app.

By default, the sencha app watch command starts the development server on the internal IP at port 1841. If you want to change the server’s port, for example to port 8082, you will have to start the server via the web command. This command will only bootu p an internal server, and won’t “watch” your app for changes. $ sencha web -port 8082 start

Want to checkout all my code? I hosted it on Github:

By the end of this part of the tutorial, you will have a working JavaScript client app, created with Sencha Cmd and Ext JS 6. The next part of this tutorial will cover the setup for creating a Node.js with Express app.*



Read the next part

Reverse Engineer the Sencha FontAwesome package to get an overview of icons.

Posted on in CSS Sass

Ext JS 6, ships with a copy of the font-awesome icon font.
Remember the Wingdings* Font from back in the days? Icon Fonts are somehow similar like that. An icon font is a (fontface) font, and every (unicode) character maps to an icon. Icon fonts are great, because they are all vectors. Therefore you can easily change the color or size, and they will always have best quality. Perfect on retina displays. You no longer need to open Photoshop to modify the icons. Because it’s text, you can add shades, change colors, backgrounds and sizes all with CSS code. (You just can’t make 3D icons / multi color icons, because it’s text.). Also, icon fonts won’t spam your screenreaders.


In Ext JS 6, font-awesome icon font is a code package, which is included in the SDK, and free to use. It’s version 4.4. which includes 585 vector icons!

You can use font packages, by enabling font awesome in your app.json file:
(when you generated the application with Sencha Cmd, this should be already there.)

"requires": [

Now you can start using the font, by adding the iconCls property to your component. For example:

   xtype: ‘button’,
   iconCls: ‘x-fa fa-globe’

The iconCls is supported on: buttons, panel titles, menu’s, tree node items, grid actions, separators and ux status bars. (That probably covers most of the places you want an icon for, but if you want icons in for example templates, you can use the below trick as well, and set icons manually.)

The big question is, how do I know, which icons are included out of the box? The easy answer is, you can use the font awesome cheatsheet:
Everything 4.4 and below will be available.

But the best answer is, you can reverse engineer this from the package yourself!
Browse to: myapp/ext/packages/font-awesome/sass/etc/


Let’s first dive into: _variables.scss. This Sass file, shows the font version number, and the CSS prefix. For Ext JS 6.2 this is:

$fa-version: "4.4.0" !default;
$fa-css-prefix: fa !default;

The _variables.scss file sets all the used variable names for every icon. However, we still don’t know how the icon will look like. Therefore, open your browser and use the Icomoon font app:

Click the Import Font button. Now browse to myapp/ext/packages/font-awesome/resources/fonts/ and select: fontawesome-webfont.svg

This will import all the font-awesome icons, which are in Ext JS. Within the Icomoon app, select all the font-awesome icons. (Select the first, hold shift and select the last.)
Then press the Generate Font button in the bottom of the app. You will now see an overview of all the icons with its used unicode. (If you want, you can download the font here, so it also saves an HTML file, with this overview.)

Ok, so now we know how the fonts look like, and what it’s unicode is. I could now, look into this list, pick the icon that I want. Copy the unicode, and lookup the variable name in _variables.scss. For example, the icon with the double music notes, has the title: uniF001, so unicode: *\f001*, which matches Sass variable name: $fa-var-music.

Once you know the variable name, copy it and open _icons.scss. Search in this file for the variable name, and it will reveal to you. For the $fa-var-music variable, it contains this Sass line:

.#{$fa-css-prefix}-music:before { content: $fa-var-music !important; }

Which will be compiled as the following CSS:

.fa-music:before { content: $fa-var-music !important; }

As you can see the CSS class fa-music, will create another node in your HTML DOM, before the element that has this CSS class, with the content that contains the unicode of the music note icon. iconCls, just adds this node in the DOM tree.

How does it know how to style the icon (for example, the color and its font-size?) That’s what the class .x-fa is for.

Note: The x-fa class should be used in Ext JS applications instead of fa which is the class you get if you download the font package from itself. The fa class sets some properties that may collide with the Sencha theme properties, whereas x-fa sets only the font-family:

.#{$prefix}fa:before {
    font-family: FontAwesome !important;

The default font-size and colors are set in _variables.scss:

$fa-font-path:        "../fonts" !default;
$fa-font-size-base:   14px !default;
$fa-line-height-base: 1 !default;
$fa-version:          "4.4.0" !default;
$fa-border-color:     #eee !default;
$fa-inverse:          #fff !default;
$fa-li-width:         (30em / 14) !default;

For the rest it’s up to you to style the icons as you like. You can do this in your theme package or app stylesheet.

*The Wingdings font was developed by Microsoft in 1990, it is actually a dingbat (a printer character used for typesetting) font. None of the characters were mapped to unicode back then, and is only available on (legacy) Microsoft platforms, therefore you should not use Wingdings for the web.


D3 Visualizations in Ext JS 6.2

Posted on in Ext JS

Ext JS 6.2 is currently in Early Access release. This means that you can try out, a version prior beta. If you run into problems, share these on the forum, or with one of the Sales Engineers, like me. Note: EA releases should never been used in production.

What’s new in this release are the Material Design theme for the modern toolkit, row body plugin for grids (for example to create grids within grids), pinch to zoom and premium components such as the Calendar Component and Pivot Grid (both for classic and modern toolkit), Exporter plugin (export Grids and PivotGrid data to CSV, XML, HTML, or Excel format) and the new D3 wrapper component.

Today, I like to talk more about this component. The D3 add-on, is part of the premium tier and will be a Sencha package (for classic and modern toolkit) which you can drop within your workspace, and whitelist via your app.json. Like this:

"requires": [

This package contains a D3 wrapper component as a base class, which will make sure the D3 SVGs will be part of the Sencha layout rendering. On top of that it will also provide support for Sencha (hierarchical tree)stores and SVG interactions.

It bundles D3.js version 3.5.14. (I'm not sure if this will change before we will release the plugin though.) The D3 library itself is open source, and there are lots of SVG examples available online.

Sencha will also ship a bunch of D3 implementations, such as: various trees, treemap, sunburst, partition, pack and hierarchy SVG charts. Check out some demos here:

Here's an example of such an implementation. This example, shows an horizontal D3 tree component, with a hierarchical TreeStore bound to it. Note also the panzoom interaction:

Now that’s easy. It comes all the way, out of the box. But what if you want to create something totally custom? Maybe you have seen a nice D3 example online, or you want to create your own chart or visualization.
You will need to understand the D3 syntax and API. This can be a bit challenging at first, though a simple example can be easily made.

First start with using the D3 base component. Ext.d3.svg.Svg will be the base class you can use:

What I have done here, is: I created a child item for my panel, and I gave it a fit layout. (Since D3 visualizations are SVGs under the hood, they need to have a height and a width, and this way it gets that from the parent panel.) I also set: scrollable to true, because, in case my D3 visualization becomes too large, I can always scroll within the component.

I use the base class Ext.d3.svg.Svg, with the xtype: d3. Once I have the wrapper, I can use the
scenesetup listener. The scenesetup has the following parameters: “component” (which is the Sencha wrapper component (a div element under the hood), you can get the layout from this component for example), and the “scene” which is the SVG scene. (A g element which will contain the visual graphics, like the rectangles and text layers in my case).

Now we can start coding D3 magic. I don’t need to query wrapper html elements. I can start right away, and use the scene variable.

Take a look into this code snippet, I’m creating here a simple bar chart. Here’s how the below component looks within my Spotifinder app:


I left comments per line, so you have an idea how the D3 API works:

Do you want to play around with this yourself? You can download the EA release here (

Or take a look into the API Docs or examples.

Questions or problems? Feel free to leave some comments.

Advanced Cmd: How to integrate Ext JS with Maven

Posted on in Environment Ext JS Ext JS 5 Ext JS 6 Uncategorized

This last article, will show you, how you can integrate Ext JS with tools like Maven.
Please understand, Maven is not a required Sencha setup, though it is possible to build your Sencha projects with Maven.

About Apache Maven

Maven is a build automation tool used primarily for Java projects. Maven addresses two aspects of building software: First, it describes how software is built, and second, it describes its dependencies. Contrary to preceding tools like Apache Ant, it uses conventions for the build procedure, and only exceptions need to be written down.
An XML Project Object Model file (pom.xml) describes the software project being built, its dependencies on other external modules and components, the build order, directories, and required plugins.

Maven is built using a plugin-based architecture that allows it to make use of any application controllable through standard input. Theoretically, this would allow anyone to write plugins to interface with build tools (compilers, unit test tools, etc.) for any other language. In reality, support and use for languages other than Java has been minimal.

Generate a Maven project for a web project

First, make sure Maven is installed on your machine. If not installed, you can follow this guide:

Once Maven is installed, we will use it to generate a web application. To do so, we can choose the webapp archetype, which has folders and settings for a (Java) web application configured:
We can run the following command from the command-line, (it’s very similar to sencha generate app, but then for Java web applications.):

mvn archetype:generate -DartifactId=NameOfProject -DarchetypeArtifactId=maven-archetype-webapp -DinteractiveMode=false

For example:

mvn archetype:generate -DgroupId=com.ladysign.MavenApp -DartifactId=MavenApp
-DarchetypeArtifactId=maven-archetype-webapp -DinteractiveMode=false

Maven will start processing and will create the complete web based java application project structure, with the following folders:

MavenApp            # contains src folder and pom.xml
src/main/webapp         # contains index.jsp and WEB-INF folde
src/main/webapp/WEB-INF  # contains web.xmlthemes
src/main/resources      # it contains images/properties files

The pom.xml (project object model), will look like this:

As you noticed, there is also an index.jsp file in the webapp folder.
This means, you should be able to see this file in your browser, after a build.

Build with Maven

Let’s build this project:

cd MavenApp
mvn clean package
(or mvn compile)

(Mac OSX users might need to prefix with sudo)
Maven will start building the project. It will create a targets folder, with a MavenApp.war file. This is the file that you can deploy, with a server like for example, Apache Tomcat.

Deploy with Tomcat

When you are new to Apache Tomcat, you can find the setup guide here:

Once Tomcat is installed, you only need to copy the war file into the webapps folder of Tomcat.
(It’s setup that easy, in /TOMCAT_HOME/conf/server.xml actually.)

Sometimes you might need to stop/start your server. Navigate on the command-line to the Tomcat app bin folder. And run:
sudo sh (or execute .bat for Windows), and (.bat).

Integrate Ext JS with Maven

Now, that we have seen how Maven works, let’s see how we can integrate an Ext JS app with a Maven web app project. Our goal is to have the Sencha build within our src/main/webapp folder. We want to automate it as much as possible, so index.jsp will contain the Sencha microloader.

I have a working example, in my Github repository, which you can find here:

These steps, will let you do the same from scratch:

1) From the downloaded ext js folder, start with generating a new workspace:

sencha generate workspace [path to the folder]/sencha

for example:
sencha generate workspace src/main/sencha

2) Navigate to the new generated sencha/ext folder

3) Then generate a new app

sencha generate app MyApp ../myapp

4) You can test the demo application by booting the sencha internal (Jetty) server, from the myapp folder, execute:

sencha app watch

Sencha spins off an internal server, it should give you the location with the port number, where it’s currently hosted. By default this will be: http://localhost:1841/myapp/

5) Great, now that it works, let see where the sencha build is located:

sencha app build

The production build is located in:

Now there are two things that we can do. We can either modify the build.xml file in the app folder, which can copy the build into the Maven folder. (Like how I described Ant build scripts, in article 2.) or we can create a Maven task for this.
Ideally we need a separate Maven task. Because by just modifying it in the build.xml, we have to run 2 tasks on the command-line. The sencha app build and the mvn clean package commands. Let’s see how we can fix this…

Build through Maven Plugins

There are 2 maven plugins that can help with building the Sencha app via Maven.

We could create a Maven task which executes Sencha Cmd via the sencha.jar that’s available in the Sencha Cmd installation folder, or we can use Maven Ant task integration, since Sencha Cmd itself is build on top of Ant.
With both solutions, you can achieve the same, it’s just a matter where you want to store your Ant tasks. In the Maven pom.xml file, or in the Sencha App build.xml file.

I will show both solutions:

Sencha Cmd execution, with the Maven exec-maven-plugin

With the exec-maven-plugin, (, you can use Maven to execute commands from the command-line.
This will require, that you have Sencha Cmd installed on the machine that runs the Maven commands.

Your pom.xml file, will look like this:

When you want to work with environment vars,
you can configure a profiles block:


See also: for my complete solution.

Ant Task runner, with the Maven maven-antrun-plugin

With the maven-antrun-plugin (, you can use Maven to run Apache Ant task. To make sure it recognizes the Sencha Ant command, you will need to have the sencha.jar somewhere on your machine. By default it’s located in the Cmd installation folder, but you could copy this over to your Maven environment/machine.

Your pom.xml file, will look like this:

See also: for my complete solution.

Here are some handy resources:

Advanced Cmd: How to modify Sencha builds

Posted on in Cmd Environment Ext JS Ext JS 5 Ext JS 6

This guide, will discuss builds, and how you can modify it, with Apache Ant.

About Apache Ant integration in Sencha Cmd.

Sencha Cmd is build with Apache Ant. You don’t need to have Ant installed on your machine, Sencha Cmd has that dependency for you, while installing Cmd.
(Sencha Cmd is delivered as a JAR file and it exposes its core functionality as an Ant Library (or antlib). The command line level of Sencha Cmd, as well as SDK-specific processing are implemented on top of this layer. So anything you can do in one, you can do in the other.)

Ant has long been a pillar of the Java development community, but at its core, Ant is an XML-based, cross-platform scripting platform. We call it a "platform" rather than a "language" because Ant can easily incorporate libraries of code in JAR form, or you can use one of the many supported scripting languages as part of your Ant script.
Ant can, of course, call other programs (like Sencha Cmd), passing arguments and processing exit codes, but what Ant is particularly good at is manipulating files. This is because Ant was designed for use with build scripts.

Copying / Removing folders with Ant

Internally, Sencha maintains many Apache Ant scripts, within the hidden .sencha folder. Ideally, you shouldn’t edit the internal Sencha build scripts, because they will be overwritten when you update Sencha Cmd.

Additionally, I don’t recommend, checking .sencha and framework folders in source control systems such like Git. You don’t want to get merge errors, when other team members have newer versions of software, running on their machines.

Therefore, every application or package contains its own build.xml file. This is the place, where you can write your own Ant tasks.

To copy folders over, I use the copy tag:

To remove folders, I use the delete tag:

Take a look into this example, that I share on Github. I created my own build script, which copies my final build, to another destination folder, and archives it, by creating a foldername that includes a timestamp:

If the only thing that you want to do, is moving the build folder to a different place on your filesystem, you might not even need a build script. Also the app.json file, has settings to control the output:

    "output": {
        "base": "${}/${build.environment}/${}",
        "page": "index.html",
        "manifest": "${}.json",
        "js": "${}/app.js",
        "appCache": {
            "enable": false
        "resources": {
            "path": "${}/resources",
            "shared": "resources"

And here are some handy links:

Advanced Sencha Cmd: Dealing with a multi Ext JS app infrastructure

Posted on in Cmd Environment Ext JS Ext JS 5 Ext JS 6

This guide will describe how to deal with an infrastructure, that contains multiple Ext JS apps.
It will discuss:

  • Local workspaces
  • How to split builds
  • How to modify file paths and output settings

About Workspaces

To support these, Sencha Cmd defines the concept of a “Workspace”. A Workspace is simply a folder that ultimately contains one or more apps (pages), frameworks, packages and other shared code or files.
The location of the Workspace root folder should be chosen to facilitate these needs as well as your source control requirements. Any generated applications/pages created in sub-folders of the Workspace folder regardless of their depth are considered to be members of the Workspace.

Though not a requirement, it is typically the case that the Workspace folder is the root folder in a source control repository.

To create a workspace, you will need to have a downloaded copy of the Ext JS framework on your hard disk, also you will need to have Sencha Cmd installed.
On the command-line navigate to the downloaded Ext JS sdk folder. From here, enter the following command:

sencha generate workspace [path to workspace]

This will generate the following folder structure:

workspace.json   # The JSON descriptor for the workspace.
ext          # A copy of the Ext JS sdk, examples/docs are stripped out
packages         # Empty folder, which will contain shared code / themes
.sencha/                # Sencha-specific files (e.g. configuration)
    workspace/          # Workspace-specific content (see below)
        sencha.cfg       # Configuration file for Sencha Cmd
        plugin.xml        # Plugin for Sencha Cmd

Within this workspace you can generate Ext JS apps, from the ext folder:

cd ext
sencha generate app MyApp ../[folder-name]

All applications within the workspace, can share the same Sencha ext folder, code packages (such as custom components, themes or locals) can be shared across both apps and also applications can find each other in the workspace. (for example, in case you want to extend from apps.)

For more information about workspaces see:

Splitting builds

By default, a workspace only matters on your development machine. Once you make a build:
sencha app build

Sencha will copy all the used framework classes and all your self written Sencha classes to a build folder. For production, all scripts will be minified. Also the Sass themes will be compiled to production ready css, and copied together with the resources.
This means, by default, all shared frameworks and code packages, will be duplicated in the production build, as they can run as stand-alones.

For most users, this behavior is exactly what they want. However, there are reasons, why people want to “split” their builds, and host code packages or frameworks separated from their app code.

Examples of such reasons are:

  • You are creating your own application framework. You are dynamically generating views, or maybe you are hosting the framework within a portal, expecting your code base will grow over time.
  • You are building a large application, with separated areas, such as an application, and an admin panel. Each of these areas, could be treated as an app itself. Which contains many views, controllers and models etc. It might be that you have different user groups visiting these apps. Why deliver them code, which they don’t need?
  • Your application became huge, and you want to split your scripts in smaller chunks.

For the last reason, there’s a good tutorial online:
Let’s dive into this topic, about splitting builds. Assuming you want to exclude the Sencha framework classes from your own app code.

In every sencha application folder, there’s a hidden .sencha folder. This hidden folder contains lots of build scripts, settings and metadata used by Sencha Cmd.
One of those files is: js-impl.xml, an Apache Ant build script, which contains an compile-js block, which takes care of filtering out all the used framework classes, and all your own JavaScript classes, to create a (minified) build:

It checks if, setting: enable.split.mode is set to true, and if so, it will split your framework with a minified, concatenated framework file & a minified, concatenated app.js file, which contains your own classes. Note, by default this setting is false.

Unfortunately, the code in the first block, doesn’t really work in Ext JS 6. But you can change it to something like below, to make it working again.
I've been playing around with this:

NOTE: I will need to test this further, but this code will need some more iterations though, I have the idea, you can union more, by tagging the Ext namespace.
Also, saving this script in js-impl.xml, is not a best practice. When you reinstall Sencha Cmd, and upgrade your app, you will loose everything that's inside the hidden .sencha folder. Instead you want to move this script out and leave it a build xml file within your project.

You can find a working example in my Github repository:

In this example, I have 2 generated Sencha apps. MyApp1 and MyApp2. Both contain a custom build file, to make sure the framework will be filtered out of the final build.

Build properties

So where is this enable.split.mode setting coming from? It’s a property file, and the hidden .sencha folder, has many properties files. You can find them all in:

To fine-tune your build, you could open, and add the props you like, for example:


Ideally you shouldn’t edit
the .properties files, these are located in the hidden sencha folder, so this means they will be overwritten when you update Sencha Cmd.
Additionally, I don’t recommend, checking .sencha and framework folders in source control systems such like Git. You don’t want to get merge errors, when other team members have newer versions of software, running on their machines.

So to make these changes, to make sure that the sencha build process, splits the build, you can make changes in the app.json file of your app:

"output": {
        "framework": {
          "path": "${}/${build.environment}/framework.js",
          "enable": true

Move the framework.js outside the app build folder

Now that we know how to split builds, or you might want to move assets / scripts around.
By default it will include framework.js and app.js in the same application folder but this will be a file, which needs to be located on a central place.

Luckily with Ext JS, you are able to move around files very easily. Many things are configurable.

In the app.json file, there will be an output block. In this block, you can rename the files, change the extension from the index page. (for example, in case you want to change it to a jsp or php file…), and you are also able to change the base path.

Once the base path is changed, you probably will need to change all the other paths as well.
Have a look into the app.json file that I wrote, or the snippets below:

The output block:

"output": {
        "base": "${}/${build.environment}/",
        "page": "${}/index.html", //you can change this to index.jsp
        "manifest": "${}/${}.json",
        "js": "${}/${}/app.js",
        "framework": {
          "path": "framework.js", //this will be the shared sencha framework stuff
          "enable": true
        "resources": {
            "path": "${}/${}/resources",
            "shared": "resources"

The archivePath, to move the archives folder:

"archivePath": "${}/archive/${}",

The appCache block, to move the app.cache file. Note, it’s also located in the production block.

"appCache": {
            "path": "${}/app.cache",
            "enable": false

The cache block, to move the delta folders:

"cache": {
        "enable": false,
        "deltas": "${}/${}/deltas"

Versioning Systems

I mentioned it before, there are a couple of scripts, you ideally don’t want to check into your source control. For Git, you can write a gitignore file, which blocks checking in the below files.
I’m sure, other versioning systems, can do the same.

There are some handy links, I like to share with you:

How to Upgrade a Sencha Touch App to Ext JS 6 Modern Toolkit – Part 1

Posted on in Ext JS 6 Sencha Touch
Cupertino Theme

Previously, I wrote a blog post on how to create great looking universal apps with Ext JS.
However, we also have lots of customers who currently have a mobile (phone or tablet) application and want to upgrade it to Ext JS 6.

In this tutorial, I will show you how you can upgrade your app, and why you should consider taking this step.

I used my existing tutorial files, “Do I need my umbrella” weather application, which I wrote a couple of years ago with Sencha Touch 2. You can find the original tutorial here. You can download the tutorial files here.

You don’t have to use these tutorial files, you can also just read through this guide and try it out with your own existing Sencha Touch 2 app.

Ext JS 6 Modern Toolkit and Sencha Touch

Ext JS has more (advanced) classes and features than Sencha Touch. You can create advanced enterprise desktop applications, and now you can also create advanced mobile applications or even advanced cross-platform apps.

We incorporated concepts from Sencha Touch 2, and merged them as “the modern toolkit” in Ext JS 5, with the modern core (class system, mvvm pattern, etc.), and there are also many updated classes. From a theming perspective, Ext JS 6 modern toolkit has been updated and looks different than Sencha Touch.

When you’re looking for an enterprise solution to create mobile apps, whether it’s a universal app or just mobile, there are many reasons why you’d choose Ext JS 6 Modern toolkit. I will explain these benefits to you in this article.

Then, I will take an example Sencha Touch 2 application, and migrate it to Ext JS 6 with the Ext JS 6 Modern toolkit.

What’s Different in Ext JS 6 Modern Toolkit

Here’s an overview of new features in Ext JS 6 compared to Sencha Touch.

Basic Upgrade

(No change to the MVVM pattern)

This upgrade allows you to use:

  • the latest mobile framework version, and support for the latest OS & browser versions
  • running your mobile application on your desktop computer too
  • controlling lists with your mouse scroll and keyboards (besides touch support)
  • new packages / theme packages structure
  • new Neptune and Triton (universal) themes
  • fast theme compilation with Fashion
  • cleaning up your models, by writing less code
  • JavaScript promises, for asynchronous code
  • out-of-the-box font-awesome integration
  • one of the new components/classes:
    • data grid
    • data tree
    • navigation tree list
    • soap, amf0, amf3 proxies
    • new charts
    • form placeholders

Advanced Upgrade

(Change to MVVM architecture pattern)

This upgrade allows you to use:

  • ViewControllers and ViewModels
    • The Stores and Controllers in MVC are global. VCs and VMs live together with a particular view, which means that they will be created with a view, and can be destroyed. ViewModels and ViewControllers therefore can improve your application performance. They also allow you to write less code and make it easier to maintain.
  • Databinding
    • Bind to data or component states. It allows you to do advanced things by writing less code.

Universal Upgrade

This upgrade allows you to:

  • Create cross-platform apps, for mobile phones and tablets, but also desktop computers. By supporting the modern (lightweight component set) and the classic rich desktop component set.
  • Support legacy browsers, like Internet Explorer 8, as well as the latest modern (mobile) browsers.

Things That Changed in the API

You can read a complete list of Ext JS 6 API changes here. The ones that I faced when upgrading the weather utility app are:

  • ViewControllers and ViewModels
    • The Stores and Controllers in MVC are global. VCs and VMs live together with a particular view, which means that they will be created with a view, and can be destroyed. ViewModels and ViewControllers therefore can improve your application performance. They also allow you to write less code and make it easier to maintain.
    • Sencha Touch has methods; in Ext 6 Modern toolkit, it’s
    • In Sencha Touch, you had to define everything in a config block; in Ext 6 Modern toolkit, you just put properties in config blocks that need the magic methods (get, set, apply, and update). Although you don’t have to, you can clean up the config blocks.
    • There are changes in the way you wire up stores that you can read about in these docs:
    • Sencha Touch validations are now called validators
    • The Sencha Touch default theme was replaced by Ext JS 6 Modern toolkit themes – Neptune and Triton.
    • The default icon set that is being used is Font Awesome, instead of Pictos.

    Basic Mobile Upgrade

    For the basic, easy upgrade, we will stick with the existing MVC pattern. You will see that it won’t take many steps. However, you won’t be taking advantage of Ext JS 6. You will have the latest framework, with all its features and classes, but you won’t be using the new MVVM pattern.

    1.  Download the Ext JS 6 (trial version).

    2.  Look in your Sencha Touch project (app.js for example), and note the namespace that was used. For example, for the Weather Application, the namespace is “Dinmu”.

    3.  Generate an Ext JS 6 modern app:

    Navigate to the ext framework folder, and generate a project with:
    sencha generate app -modern
    For example:
    ext> sencha generate app -modern Dinmu ../dinmu1


    4.  Go to the project in your browser, you should see the new Ext JS 6 demo app.

    5.  In your file system, rename the <myproject>/app folder to something else (like app-backup)

    6.  Do the same for the app.js file; rename it to app-backup.js

    7.  Then, copy the app folder and the app.js from your Sencha Touch project, and paste it in your new Ext JS 6 project.

    In case you are loading external JS or CSS files via app.json, you can manually merge those lines into the new app.json. My advice is to do these kind of steps at the end, after you have your app running.

    8.  Run the following command from the command-line:

    1. sencha app refresh
    2. You might run into build errors here, because of API changes. For the Dinmu app, there was an error because Ext.device.Geolocation has been deprecated.
    3. When you have lots of custom components, you may run into problems here. The best way to solve them is to read the messages from the CLI, and open the Modern toolkit API docs to search for the classes that fail. In my case, it was the geolocation class that failed. In the docs, I noticed that there are no device APIs anymore. In Sencha Touch, these classes where wrappers for PhoneGap/Cordova support, that would fall back to the HTML5 API feature, if available in the browser. There is Ext.util.Geolocation, so I changed the code to use it. After I changed the line, I ran another sencha app refresh again, to check for more errors. See the results here.

    9.  When you don’t have any more errors anymore, you can try to run the application in the browser. When I ran my app, I got a console error in my app.js launch method.‘appLoadingIndicator’).destroy();

    Basically, this is an error that tells you that you can’t destroy the “appLoadingIndicator” element, just because it’s not there. The index.html is just different. Now you don’t want to replace the index.html file, with the Sencha Touch one, because the calls to the microloader are different. It’s up to you, if you want to remove this destroy line in the app.js launch method, or if you take over the <style> and <body> tags from the Sencha Touch app. I liked the Sencha Touch simple CSS preloader, that you will see before loading any JS or CSS, so that’s why I took over those tags. After fixing this problem, I was able to open my Ext JS 6 app in the browser.

    10.  The application is running a bit odd. By inspecting my application, I noticed that in my Sencha Touch application I have controllers with launch methods. And launch methods on controllers don’t exist in Ext JS 6, instead they’re called: onLaunch. So I renamed it, and ran the application again.

    11.  This time I had a problem with the store. The store manager couldn’t find Ext.getStore('Settings'), because it was wired up to the controller like this: Instead, the store manager has to access it via the full class name. I fixed it in the controller, instead of wiring up the full path, and I just passed in the Store name.

    12.  The settings button was not visible; this was due the changes in the icon sets. I used the default font-awesome settings icon, and changed the iconCIs in the Settings button in Main.js to: x-fa fa-cog


    13.  Last step was to run a build to make sure that I was able to build my application. I expected it to work, because the sencha app refresh command did not fail.

    And that’s it. After this last step, I was able to run the Weather Application as a full working Ext JS 6 mobile app.

    Coming Up Next

    In the next article in this series, I’ll show you how to do the advanced upgrade, where we will switch to the new MVVM pattern, and we can also clean up some code.