CoreMedia Studio Manual, Version 7.5.45-10
Chapter 5. Concepts and Technology | 5.2. Ext JS with ActionScript and EXML

While the CoreMedia Studio code you see at runtime is all JavaScript, CoreMedia Studio is completely written in ActionScript and EXML, an XML format to describe components declaratively. CoreMedia calls this combination of tools and approach Ext AS (where obviously, "ActionScript" replaces the "JavaScript" in Ext JS.

Ext AS is designed to provide a statically typed way to implement Ext JS applications. EXML is used to declaratively describe Ext UI components (or component trees), validated through a W3C standards compliant XML Schema. During the build process, EXML files are compiled down to ActionScript 3, which in a second step are then compiled further to JavaScript. For localization, property files can be converted to ActionScript classes, too, so that you can access a localization key as if it was a constant defined in a class.

While it is possible to extend CoreMedia Studio with components written in JavaScript, it is recommended to use Ext AS. With the Jangaroo project, CoreMedia offers Open Source tools and libraries that provide complete support for this development approach. All public CoreMedia Studio APIs are available as ActionScript 3 ASDoc and source stubs, so that you can set up your IDE to provide code completion, validation, and documentation lookup.

This section states the rationale for using Ext AS, gives you a rough overview of the approach and tools, and contains references to the detailed online documentation, which is part of the Jangaroo open source project.

Ext AS: the Typed Version of Ext JS

In contrast to JavaScript and JSON, ActionScript and EXML are typed languages. While originally, typed languages were chosen to find errors early at compile time, the more important advantage today is that much better tools can be built to ease and speed up development. In a good IDE, errors and possible mistakes are detected as you type, and the IDE even makes suggestions as to what to type next, how to resolve errors, and lets you look up documentation easily. Using a typed language is important for the IDE to be able to derive what the code is referring to. With an untyped language, only limited IDE support is possible, and the IDE has use more or less imprecise heuristics, and will in many cases make ambiguous (or even erroneous) suggestions.

Source File Types and Compilers

CoreMedia Studio is an Ext AS application and as such uses four different kinds of source files:

Consequently, the Jangaroo tool set contains three compilers:

The first two compilers are chained with the last one, resulting in pure JavaScript output. CoreMedia chooses to let the additional compilers generate ActionScript, not JavaScript directly, as the generated ActionScript classes are better suited for access from ActionScript code, and integrate seamlessly in Jangaroo's lazy class initialization and automatic class loading.

Fitting into the Maven build process, all compilers are usually invoked through Maven, but there are also plugins for IntelliJ IDEA that extend IDEA's incremental build process and invoke the compilers directly, resulting in a much faster turnaround. Currently, CoreMedia strongly recommends using IntelliJ IDEA 10.x for Jangaroo development for highest productivity.

Online Jangaroo Documentation

Since CoreMedia is not primarily a manufacturer of development tools, all these tools are released as open source under an Apache 2 license. Consequently, the tools are not documented here, but on the Jangaroo Website and in Jangaroo's Wiki.

Since the CoreMedia Project workspace uses Maven, you can ignore all references to direct compiler command line interfaces or Ant. When starting with Jangaroo development, it is recommended to work through the documentation in the following order:

If you have questions about any Jangaroo tool, please post in the Jangaroo user group. You can also write an email to info@jangaroo.net.

If the question or problem is Studio related, please contact CoreMedia support.

ActionScript Documentation

Being integrated in our ActionScript programming model, the documentation of all Ext JS components and public API components of CoreMedia Studio is accessible through the ASDoc (ActionScript Documentation) linked from the Studio's most recent release page, which is available at the CoreMedia download section or from our documentation site at http://documentation.coremedia.com.

In the ASDoc, you will find two ActionScript classes per component. One class represents the component itself. This component class describes the type of the component at runtime, for example when registering event listeners or when updating the state of the component. For Ext JS components, the name and package of each class matches the official Ext JS documentation by Sencha, except that the top-level package is ext instead of Ext.

A second class defines the component's configuration time API, that is, when you create a JSON configuration object or an EXML component definition. Configuration classes are by convention placed in a package ending in config. For Ext JS components, all configuration classes are located in the package ext.config and are named like the xtype (or ptype for plugins) of the component. For Studio components, the name of the configuration class is identical to that of the component class, but with a lowercase initial character, and the package is chosen based on the module in which the component is defined:

By convention, the inheritance hierarchy of configuration classes matches the hierarchy of component classes.

Configuring Components

Each configuration class defines the configuration attributes of that class. You can use instances of the configuration classes for configuring Ext JS components in a type-safe way, although it is still possible to write component configurations as a plain JSON object. The code fragments

ComponentMgr.create({
  xtype:
    "com.coremedia.cms.editor.sdk.config.stringPropertyField",
  itemId: "linktextEditor",
  propertyName: "linktext"
}, null);

and

var stringPropertyFieldConfig:stringPropertyField =
  new stringPropertyField();
stringPropertyFieldConfig.itemId = "linktextEditor";
stringPropertyFieldConfig.propertyName = "linktext";
ComponentMgr.create(stringPropertyFieldConfig, null);

and

ComponentMgr.create(new stringPropertyField({
  itemId: "linktextEditor",
  propertyName: "linktext"
}), null);

are equivalent. Choose a programming style that suits you. Note however that the most convenient (and thus recommended) way to write component configurations is to use EXML rather than ActionScript.

The last example shows how a configuration class itself can be initialized untyped, while still allowing typed accesses later. Note that an instance creation performed in this way is not the same as a type cast: The xtype attribute of the configuration object is set implicitly when the constructor is run.

When developing with EXML, you don't have to deal with the ActionScript code manually: The EXML compiler automatically generates code equivalent to the third variant shown above. In this case, the reduced type checking is offset by the checks at XML level during development.

EXML files are described in more detail in the Jangaroo tools wiki. The namespaces to use in EXML files in the context of CoreMedia Studio are: