GateIn 3.4 M1 is the first milestone for the upcoming 3.4 release, it provides two new features: JavaScript modules and mobile redirect. You can download the release from this page, try it and give us feedback in the forums.

Matt blogged a few days ago on the mobile redirection, so I will just highlight the improvements that were made on the JavaScript side and explain why it is a key feature of GateIn 3.4.

GateIn is an aggregation platform, until now you used GateIn as an efficient way for aggregating markup in a web page. With the rise of JavaScript, GateIn is now a platform for aggregating JavaScript. The only correct way for aggregating scripts in a page is to use the JavaScript Module pattern, supporting JavaScript modules in GateIn is a key point and that's what we achieve with GateIn 3.4.

GateIn 3.3 improved by far the management of Javascript in GateIn focusing on two aspects :

• Cacheable URL for Javascript: for instance by including script characteristic in the URL like the GateIn release number, the minified flag and so on.
• Lazy loading of script: loading triggered by a portlet or a portal, dependency management between scripts, parallel loading, etc...

Our initial goal was to improve web performances and we achieved it. The 3.4 release add two missing pieces to the puzzle: isolation and asynchronicity. The Requires.JS implements the Asynchronous Module Definition and is a tiny piece of Javascript that focuses on delivering those two pieces and we integrated it in GateIn 3.4. In fact we replace GateIn custom Javascript loader by Requires.JS loader.

The key difference with GateIn 3.3 is how JavaScript is managed and how dependencies are connected between each other. In GateIn 3.3 you can provide script that would consume and produce global modules:

producedModule = {
  service : function() {
     consumedModule.service();
  }
};

With asynchronous module, the script is written a bit differently:

_module = {
   service : function() {
      consumedModule.service();
   }
};

This script is declared in the gatein-resources.xml descriptor as a module:

<module>
   <name>producedModule</name>
   <script>
      <name>MyScript</name>
      <path>producedModule.js</path>
   </script>
   <depends>
      <module>consumedModule</module>
</module>

The change here is that now we use the implicit variable _module, in reality when you do this script, the whole script is wrapped by GateIn thanks to the XML declaration:

define("producedModule", ["consumedModule"], function(consumedModule) {
   var _module = {};
   // your code wrapped here
   return _module;
});

The define function is a Requires.JS construct and from here the code evaluation (i.e the module definition) will be entirely managed by Requires.JS. Requires.JS will do its best to load the module asynchronously and in parallel to deliver the best performances. This JavaScript construct provides the two essential things we are looking for:

1. The execution of the script is deffered until it's really needed thanks to the function wrapping the code
2. Isolation works because we the function arguments are used instead of the globally scoped variables and the returned _module

We expect to release GateIn 3.4 around september with those two features finished. GateIn 3.4 will provide two key features : mobile redirection support and JavaScript modularity.