I. Introduction

+ +

Ext JS 4 is by far the biggest overhaul weâve ever made to Ext JS, and constitutes the most advanced JavaScript framework ever created. Almost every area of the framework has been upgraded, from the generated HTML to the class system. Weâve unified APIs, added incredible new capabilities, and improved the performance of the entire framework.

+ +

With Ext JS 4 weâve been driven by three key goals: speed, robustness and ease of use. We wanted the framework to be as fast and as robust as possible on every browser, and to be easy to learn and use. To achieve this we took the whole framework back to the drawing board, and what weâve come back with is the fastest, most bullet-proof version of Ext JS weâve ever created. Best of all, weâve managed to do it while staying true to the core experience of writing apps âthe Ext JS way.â

+ +

II. Getting Started

+ +

1. Requirements

+ +

1.1 Web Browsers

+ +

Ext JS 4 supports almost any known web browsers, from Internet Explorer 6 to Chrome 11. During development, we recommend that you choose one of the following as the primary browsers for the best debugging experience:

+ +

1.2 Debugging Tools

+ +

Please refer to the dedicated Debugging Handbook guide on the recommended tools for each and every browser, as well as how to make use of them to aid development.

+ +

1.3 Web Server

+ +

Even though a local web server is not a requirement to use Ext JS 4, it is still highly recommended that you develop with one, since XHR over local file:// protocol has cross origin restriction on most browsers.

+ +

1.4. Ext JS 4 SDK

+ +

Download Ext JS 4 SDK if you haven't done so. Unzip the package within your web root directory tree. This guide assumes that http://localhost/ext-4.0 points to the top level directory of the downloaded SDK.

+ +

Open http://localhost/ext-4.0/index.html on your web browser. If a welcome page appears, you are all set.

+ +

2. Application Structure

+ +

Although not being mandatory, all suggestions listed below should be considered as best-practice guidelines to keep your application well organized, extensible and maintainable.

+ +

2.1 Basic Structure

+ +

- appname
+    - app
+        - namespace
+            - Class1.js
+            - Class2.js
+            - ...
+    - resources
+        - css
+        - images
+        - ...
+    - app.js
+    - index.html

+ +

in which:

+ +

appname is a directory containing all your application's source files
app contains all your classes, the naming style of which should follow the convention listed in the Class System guide
resources contains additional CSS and image files which are responsible for the look and feel of the application, as well as other static resources (XML, JSON, etc.)
index.html is the entry-point HTML document
app.js contains your own application's logics

+ +

An Ext JS application is self-contained in a single HTML document, the content of which has this format:

+ +

<html>
+<head>
+    <title>Application Name</title>
+
+    <link rel="stylesheet" type="text/css" href="path/to/sdk/resources/css/ext-all.css">
+    <script type="text/javascript" src="path/to/sdk/ext-debug.js"></script>
+    <script type="text/javascript" src="app.js"></script>
+</head>
+<body></body>
+</html>

+ +

whereby:

+ +

path/to/sdk points to Ext JS 4 SDK directory in section 1.4
path/to/sdk/resources/css/ext-all.css contains all styling information needed for the whole framework
path/to/sdk/ext(-debug).js contains Ext JS 4 Core library (or path/to/sdk/ext-all(-debug).js, as explained below)

+ +

From this point you need to choose between 2 different library inclusion methods. Each has its own pros and cons listed below:

+ +

Include path/to/sdk/ext-all.js (path/to/sdk/ext-all-debug.js during development), which contains the whole framework.
- Pros:
  - There is no need to worry about dependencies when using default Ext JS components (but not your own custom classes)
- Cons:
  - Deployment file size could be unnecessarily large if your application doesn't make use of everything the library has to offer. That, as a consequence, would lead to slower application initialization due to unnecessary script execution as well as network data transfer overheads.
  - Debugging is difficult due to the fact that all source code is confined into one big file.
Include path/to/sdk/ext.js (path/to/sdk/ext-debug.js during development) which contains just the minimum core library, and make use of Ext.Loader for automatic dependencies resolution.
- Pros:
  - Your application only loads exactly what it needs as you develop. Deployed file size will be minimal.
  - Debugging is simple and straight-forward since all source files are loaded separated. Errors messages come with the exact line numbers and file names from which they occur.
- Cons:
  - Attention to dependencies when using default components shipped with the SDK is needed

+ +

In summary, it is recommended that you should only use ext-all(-debug).js if you need to shorten the initial learning curve. Otherwise, ext(-debug).js is preferred in most cases for actual application development.

+ +

Last but not least, app.js is the entry-point of your own application's logic. For a basic application, the typical format of which may look like this:

+ +

// Register namespaces and their corresponding paths to Ext.Loader
+Ext.Loader.setPath({
+    'AppName': 'app',
+    ... // Other namespaces
+});
+
+// Specify a list of classes your application your application needs
+Ext.require([
+    ...
+]);
+
+// Application's initialization
+Ext.onReady(function() {
+
+    ...
+
+});

+ +

2.2 MVC (Model-View-Controller) Structure

+ +

Ext JS 4 shipped with a robust MVC architecture which maximize extensibility and maintainability for medium to large scale applications. Please refer to the MVC Application Architecture guide for detailed instructions.

+ +

3. Deployment

+ +

The newly introduced Sencha SDK Tools (download here makes deployment of any Ext JS 4 application easier than ever. The tools allows you to generate a manifest of all dependencies in the form of a JSB3 (JSBuilder file format) file, and create a minimal custom build of just what your application needs within minutes.

+ +

Once you've installed the SDK Tools, open a terminal window and navigate into your application's directory.

+ +

cd path/to/application

+ +

From here you only need to run a couple of simple commands. The first one generates a JSB3 file:

+ +

sencha create jsb -a index.html -p app.jsb3

+ +

This scans your index.html file for all framework and application files that are actually used by the app, and then creates a JSB file called app.jsb3. Generating the JSB3 first gives us a chance to modify the generated app.jsb3 before building - this can be helpful if you have custom resources to copy, but in most cases we can immediately proceed to build the application with the second command:

+ +

sencha build -p app.jsb3 -d .

+ +

This takes the JSB3 file and creates an app-all.js, which is a minimized build of your application plus all of the Ext JS classes required to run it. It also creates an all-classes.js file, which has the same classes as app-all.js, but is not minified so is very useful for debugging problems with your built application. In short, app-all.js is the minified and production-ready version of all-classes.js + app.js.

+ +

Most applications will need a separate index.html for the deployed version of the app, for example to add Analytics includes or other production-only logic into that file. Typically you would end up with a production index.html file that looks like this:

+ +

<html>
+<head>
+    <title>Application Name</title>
+
+    <link rel="stylesheet" type="text/css" href="path/to/sdk/resources/css/ext-all.css">
+    <script type="text/javascript" src="path/to/sdk/ext.js"></script>
+    <script type="text/javascript" src="app-all.js"></script>
+</head>
+<body></body>
+</html>

+ +

Notice that path/to/sdk/ext-debug.js has been replaced with path/to/sdk/ext.js, and app.js has been replaced with app-all.js in this production version, comparing with the development one described in section 2.1

+ +

For applications built on top of a dynamic server-side language like PHP, Ruby, ASP, etc., you can simply replace index.html in the first command to the actual URL of your application. This URL should be the same with what is viewable on the browsers during development. For example:

+ +

sencha create jsb -a http://localhost/path/to/application/index.php -p app.jsb3

+ +

This guide is a work in progress.

+ +

Please check back soon