GateIn is the open source portal framework that serves as the backbone of eXo Platform, and the upcoming GateIn 3.2 will provide eXo Platform 3.5 with a set of great portal features. GateIn 3.2 is a logical evolution of the GateIn 3.1 release; the vision is to improve the project and continue the implementation of what we started with GateIn 3.0. In this post, I will describe a few of GateIn’s numerous new features.
Navigation Controller
The navigation controller is a major change that could be summarized as the decoupling of URL expression and URL processing in GateIn. This means that:
- URLs processed by GateIn can be easily changed because they are now declared in an XML file
- Friendly URLs are now supported, giving the portal administrator freedom to configure how http URLs should appear
Desktop Mode
A new Desktop Mode feature was developed for the eXo Platform 3.5 release, and we’ve already updated it to run on top of GateIn 3.2. While providing a desktop experience to your sites, this new feature also gave us an opportunity to polish the UI and bring a few more improvements:
- Ability to upload desktop backgrounds
- Revamped dock UI
Site Describability
Sometimes there are features that are difficult to name. We had one in this version of GateIn, which we decided to call site describability. This new feature enhances GateIn’s usability by allowing the administrator to provide a display name and description for a portal site. Here are a couple of screen shots to show you what I’m referring to:
Navigation is an important concept in GateIn that allows web pages to be organized as a hierarchical navigation tree for portals and groups. Internationalization in navigation was supported until now with the help of resource bundles by providing a label containing a specific expression (like ${portal.home} for instance). In some cases this approach is not dynamic enough because, in order to to handle custom resource bundle keys, it requires a resource bundle to be updated when a new navigation node is added.
GateIn 3.2 will include fully dynamic support of navigation i18n. The setup can be done easily in navigation.xml file in a similar fashion of portlet.xml (using the xml:lang attribute to specify a language) deployment descriptor. You can watch a video of this feature on this page.
Of course it is also possible to edit the navigation i18n labels in the user interface:
Portal Public Parameters
As a portlet developer, you often need to extend the GateIn server and create portlets that interact with the environment. So you will likely enjoy this new feature, which allows you to obtain contextual information like the current navigation URI, the current page name and so on. The best thing about this feature is that it leverages the JSR 286 API to get this information in a very intuitive and natural fashion. If you think about it, the most adapted way to obtain this information is via the public render parameter API. This feature is therefore very easy to use, as the only thing you need to do is to declare a specific public render parameter in your portlet XML deployment descriptor. For instance, if you want to obtain the current site name, you will need to declare:
<portlet>
...
<supported-public-render-parameter> site_name < /supported-public-render-parameter >
...
</portlet>
<public-render-parameter>
<identifier>site_name</identifier>
<qname xmlns:prp='http://www.gatein.org/xml/ns/prp_1_0'>prp:site_name </gname>
</public-render-parameter>
And voilà, at run-time you can get the current site name by using the portlet request render parameters, pretty much like:
protected void doView(RenderRequest req, RenderResponse resp) throws PortletException, IOException {
...
writer.println("The current site is " + req.getParameter("site_name"));
...
}
Everything we thought might be useful to a portlet developer to see was done (and if you think that we forgot something useful, don’t hesitate to tell us, or even better contribute it!):
- navigation_uri: the current navigation URI
- page_name: the current page name
- site_type: the current site type (“portal” for portal, “user” for dashboard, “group” for group)
- site_name: the current site name
- window_width: the current window width
- window_height: the current window height
Performance
No major release of GateIn would be complete without performance improvements. In this release we focused on the improving how GateIn loads a site’s navigation tree. The navigation tree used to be entirely loaded from the Java Content Repository and was eventually an issue for sites using a large navigation. Our team worked hard to improve it, and the result is the capability to load navigation fragments instead of the whole tree, while simultaneously keeping the user interface consistent. As a bonus it improved the concurrent edition of the navigation and now we are glad to support concurrent real-time editions of the navigation, as you can see in this video.
Finally
We also made a lot of minor enhancements that will make your life with GateIn better. Here are the ones I think are most relevant:
- Resource compressor: we provide pluggability for resource compression (JavaScript and CSS), and we integrate the YUI and Google Clojure compressors by default. It works with a system of plugins; if you want to change the configuration you can have a look at the resource-compressor-configuration.xml file. You can even develop your own compressor if you want.
- A drop-down list for portal or group sites when adding a new page: it’s a minor usability enhancement, yet convenient.
- A lot of work was done to make the deployment of the WSRP service more modular in JBoss AS, just how it used to be in JBoss Portal.
- The portlet container session life cycle could sometimes have a lifetime greater than that of the portal, especially when a logout was performed. We fixed this issue, so now a logout on GateIn invalidates pending portlet sessions.
Check out JBoss.org for the latest downloads, and be on the lookout for previews of eXo Platform 3.5…
![[Bloglines]](http://blog.exoplatform.org/wp-content/plugins/bookmarkify/bloglines.png)
![[BlogMarks]](http://blog.exoplatform.org/wp-content/plugins/bookmarkify/blogmarks.png)
![[del.icio.us]](http://blog.exoplatform.org/wp-content/plugins/bookmarkify/delicious.png)
![[Digg]](http://blog.exoplatform.org/wp-content/plugins/bookmarkify/digg.png)
![[dzone]](http://blog.exoplatform.org/wp-content/plugins/bookmarkify/dzone.png)
![[Facebook]](http://blog.exoplatform.org/wp-content/plugins/bookmarkify/facebook.png)
![[Furl]](http://blog.exoplatform.org/wp-content/plugins/bookmarkify/furl.png)
![[Ma.gnolia]](http://blog.exoplatform.org/wp-content/plugins/bookmarkify/magnolia.png)
![[Newsvine]](http://blog.exoplatform.org/wp-content/plugins/bookmarkify/newsvine.png)
![[Reddit]](http://blog.exoplatform.org/wp-content/plugins/bookmarkify/reddit.png)
![[Slashdot]](http://blog.exoplatform.org/wp-content/plugins/bookmarkify/slashdot.png)
![[StumbleUpon]](http://blog.exoplatform.org/wp-content/plugins/bookmarkify/stumbleupon.png)
![[Technorati]](http://blog.exoplatform.org/wp-content/plugins/bookmarkify/technorati.png)
![[Twitter]](http://blog.exoplatform.org/wp-content/plugins/bookmarkify/twitter.png)
![[Email]](http://blog.exoplatform.org/wp-content/plugins/bookmarkify/email.png)