About OpenWGA 6.2
OpenWGA 6.1 is now almost four months old and it is about time for us to talk about our plans for its successor version. The work for it is in full progress, and while we're again behind schedule regarding our original plan for creating feature releases it won't again take a full year for it to get available.
In fact it is scheduled to be released in not too far time on 9nd September (Update: We had to postpone the release for a week due to outstanding issues). So let's have a look at what is planned for the second installment of OpenWGA 6 feature releases.
Arguably the biggest change in OpenWGA 6.2 will be the completely refactored WebTML portlet framework. This part of (Open)WGA has come a long way since its birth with version 2.2 in 2004 and has proven to be an important and capable building block for content-driven applications, used in virtually every real "application" we have done on the platform. Let's dive a bit deeper into its history and the reasons for change.
Back then, when the WebTML portlet framework was designed, it was intended for a completely different usage scheme than it is used today. In 2004 full-fledged "web portals" were the rage, feature-filled starting pages with customizable application parts called "portlets", which the user himself could choose, arrange and configure to his liking. Because of this WebTML portlets are written to a registry on the user profile, so each user could create her/his individual set of portlets and persist it.
Today the web has mostly survived portals and WebTML portlets are used quite differently, rather seldomly for something like a portal. They are still a capsuled part of a web applications design, capable of serving a purpose without influencing the rest of the site. However, it is not the users individual registry that decides today which portlets are shown. Instead it is the application state - the addressed URL, portlet modes, session variables etc. - which decides what portlets are currently visible. The registry is still there, still filled for each single portlet, but almost never asked what is actually registered.
This has some implications. At first there is some - sometimes a lot - of unused data written to the user profile, which takes time and disk space to store. Also this session-wide registry prevents portlet applications to work correctly when used from multiple browser windows. With this usage scheme the registrations from different windows, showing different parts of the application, conflict each other. Only one state can be persisted to the user profile at one time.
All this was taken into account while designing the new OpenWGA 6.2 Transient Portlet Framework. The registry has factually gone, a portlet is only registered for the current request. It however is still able to store session variables and portlet configuration items, in case it needs them, for later instances of the same portlet to retrieve. Only portlet configuration items are actually stored to the profile. Besides that the database storage footprint of each portlet is zero.
Another big change: The state of a portlet - its mode, context and session variables - is no longer stored on the server but on the browser client, using the browser windows local storage (utilizing modern HTML5 technologies, if available). From there it is transmitted back to the server to create individual requests for the current state. This allows each browser window to act completely independent of other windows regarding its portlets.
With OpenWGA 6.2 the OpenWGA Content Manager and Admin Client will start to use the new portlet framework, and be multi-window-compatible, as can every other application running on OpenWGA 6.2. Our experience has shown that in most cases it is a snap to convert an application to using the new framework. However, existing applications will continue to use the legacy portlet framework after upgrading to keep downward compatibility, at least until explicitly told to use the new one.
On to the next page...