2.13.1. Overview of GateIn JavaScript

GateIn JavaScript improvements are built on the top of the notion of JavaScript module. JavaScript does not provide a natural way for namespacing and the notion of module was designed to solve this problem. Namespacing can be perceived as a natural lack, however this lack should be seen as an advantage as modules provide more and more namespacing. Indeed, the module pattern allows creating and resolving dependencies between modules at runtime on demand and loading JavaScript resources in parallel.

To further understand modules, see the RequireJS documentation. You can also read the excellent article written by Ben Cherry about modules in depth.

Module in Ecmascript 6

Ecmascript 6 will provide native modules that you can read more in this article.

In the essence, the notion of module can be viewed as:

An identifier or name.
A list of dependencies on the modules required to work properly.
The code packaged is usually expressed as a self-executing function. The product which is an object produced by the module that is usually consumed by other modules.

At runtime, the dependency system defines a graph of function to execute, the product of each module being injected in the other modules. It can be seen as a simple dependency injection system which can load modules in an asynchronous and parallel fashion providing parallel loading, namespacing and dependency management.

GateIn 3.5 supports different module formats:

GateIn Module Definition (GMD): The most appropriate way to define a JavaScript module in GateIn. The module is expressed as a simple function, and the list of dependencies is expressed in the gatein-resources.xml file. This format clearly decouples the module code in a JavaScript file from the module dependencies expressed in a single XML file and is the best trade off for integrating JavaScript in GateIn.
Asynchronous Module Definition (AMD): The native module format supported by RequireJS.
Adapted Module: This format is the most flexible one as it allows adapting to another module format, such as CommonJS modules.

You can see another benefits of modules by writing a module consuming the jQuery library as the following example:

(function($) {
  $("body").on("click", ".mybutton", function(event) {
    alert("Button clicked");
  };
})($)

The JavaScript side of the module is a merge function that takes the jQuery $ object as an argument:

The jQuery object is provided as a module dependency expressed as a function argument $. The module code can use the same name as jQuery. In the module, the $ name can be used. The $ jQuery can be used without the $.ready function because jQuery will be loaded and initialized once the function is executed.
The module is scoped to the entire page and this code will react to any click on the .mybutton selector.

Now integrate this module in GateIn by declaring it in the gatein-resources.xml file of the war file:


<gatein-resources

  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

  xsi:schemaLocation="http://www.gatein.org/xml/ns/gatein_resources_1_3 http://www.gatein.org/xml/ns/gatein_resources_1_3"

  xmlns="http://www.gatein.org/xml/ns/gatein_resources_1_3">

  <portlet>

    <name>MyPortlet</name>

    <module>

      <script>

        <path>/mymodule.js</path>

      </script>

      <depends>

        <module>jquery</module>

        <as>$</as>

      </depends>

    </module>

  </portlet>

<gatein-resources>