Skip navigation
2012

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.

Some updates on what is happening on the mobile front with GateIn. We now have user agent (ie browser) detection and can configure site redirections based on that. Woot!

 

 

If you are using GateIn 3.4.0, you may already notice some changes:


 

  • If you access the site using a mobile browser, you will be automatically directed from the default classic page to the new "mobile" page. Ok, the ‘mobile’ site isn’t really mobilized yet in terms of mobile optimized html, javascript and css, this will be coming in a future update. But the device detection and redirection part is up and running. Try accesing the default portal using different devices and see for yourself.

 

 

  • You may also notice a new site preference portlet at the bottom of the portal page. This allows users to select which site preference they want. So if a user decides they don’t want to be redirected to the mobile page, thats cool, they can just click on the site preference portlet and be taken to their site of preference. And since their preference is stored in a cookie, their choice is remember on each subsequent visit to the site. No redirects? Thats fine, the portlet will remain invisible on the page if there isn't any.

redirect-portlet.png

 

A few caveats through:

  • Its currently only configurable through the portal.xml configuration file, and there is no gui (yet) for the configuration. So its not going to be the easiest things to configure right now.
  • As already mentioned, mobile optimized html, js and css is not there yet and will be coming in a future update. Yeah, this sucks and takes a away a lot of the functionality of a mobile iniative, but GateIn's skinning engine is powerful enough and should allow people to create their own awesome mobile enabled portal skins until we get a default mobile skin up and running. The skinning engine should also be updated in a newer release to handle some of the unique requirements of mobile development (like skin specific javascript and meta tags).


Stay tuned for future updates.

 

So lets focus on what is working and available today:

 

User Agent Detection

We can detect the user agent (ie browser) the current is currently using to access the site using the contents of the user agent string passed in from the browser itself or redirect to a special page to check the capabilities of the browser (for things like pixel density and touch event support). Can both be used together or separately, and uses things like regular expressions to give it some power.


Site Redirection

Ok, so we now know how to detect a user agent, now what? Well, the next steps is configuring the portal to redirect between the normal site and an 'alternative’' site (I guess we could call it the 'mobile' site here, but since we don't have a mobile ui done yet, its a bit getting ahead of ourselves). We support mapping specific nodes between the different sites as well as various strategies on how to handle nodes which don’t exactly match up.

 

And how do you configure all of this? Check out the docs available here: Gatein Device Detection and Site Redirection Configuration

 

Thats it for the mobile updates for now, stay tuned for future updates!