module Ext_app_Application: sig .. end

Represents an Ext JS 4 application, which is typically a single page app using a Viewport. A typical Ext.app.Application might look like this:

Ext.application({
    name: 'MyApp',
    launch: function() {
        Ext.create('Ext.container.Viewport', {
            items: {
                html: 'My App'
            }
        });
    }
});

This does several things. First it creates a global variable called 'MyApp' - all of your Application's classes (such as its Models, Views and Controllers) will reside under this single namespace, which drastically lowers the chances of colliding global variables. The MyApp global will also have a getApplication method to get a reference to the current application:

var app = MyApp.getApplication();

When the page is ready and all of your JavaScript has loaded, your Application's launch function is called, at which time you can run the code that starts your app. Usually this consists of creating a Viewport, as we do in the example above.

Telling Application about the rest of the app

Because an Ext.app.Application represents an entire app, we should tell it about the other parts of the app - namely the Models, Views and Controllers that are bundled with the application. Let's say we have a blog management app; we might have Models and Controllers for Posts and Comments, and Views for listing, adding and editing Posts and Comments. Here's how we'd tell our Application about all these things:

Ext.application({
    name: 'Blog',
    models: ['Post', 'Comment'],
    controllers: ['Posts', 'Comments'],

    launch: function() {
        ...
    }
});

Note that we didn't actually list the Views directly in the Application itself. This is because Views are managed by Controllers, so it makes sense to keep those dependencies there. The Application will load each of the specified Controllers using the pathing conventions laid out in the application architecture guide - in this case expecting the controllers to reside in app/controller/Posts.js and app/controller/Comments.js. In turn, each Controller simply needs to list the Views it uses and they will be automatically loaded. Here's how our Posts controller like be defined:

Ext.define('MyApp.controller.Posts', {
    extend: 'Ext.app.Controller',
    views: ['posts.List', 'posts.Edit'],

    //the rest of the Controller here
});

Because we told our Application about our Models and Controllers, and our Controllers about their Views, Ext JS will automatically load all of our app files for us. This means we don't have to manually add script tags into our html files whenever we add a new class, but more importantly it enables us to create a minimized build of our entire application using Sencha Cmd.

Deriving from Ext.app.Application

Typically, applications do not derive directly from Ext.app.Application. Rather, the configuration passed to Ext.application mimics what you might do in a derived class. In some cases, however, it can be desirable to share logic by using a derived class from Ext.app.Application.

Derivation works as you would expect, but using the derived class should still be the job of the Ext.application method.

Ext.define('MyApp.app.Application', {
    extend: 'Ext.app.Application',
    name: 'MyApp',
    ...
});

Ext.application('MyApp.app.Application');

For more information about writing Ext JS 4 applications, please see the application architecture guide.

class type t = object .. end

class type configs = object .. end

class type events = object .. end

class type statics = object .. end

val of_configs : configs Js.t -> t Js.t

val to_configs : t Js.t -> configs Js.t