Message Driven Framework for decoupling UI Portlets / UI Modules (ExtJS 4 Sample)

Hey, Hope all of you are having nice time out there.. Today I am interested in sharing one of my own framework how to create totally decoupled GUI apps. But, what does that mean? Well, that ‘s a million dollar question that needs to be understood first before we start talking about the solution . One best example I can quote today for you is Portlets.

What are portlets? Wikipedia says, Portlets are pluggable user interface software components that are managed and displayed in a web portal. Portlets produce fragments of markup code that are aggregated into a portal. Typically, following the desktop metaphor, a portal page is displayed as a collection of non-overlapping portlet windows, where each portlet window displays a portlet. Hence a portlet (or collection of portlets) resembles a web-based application that is hosted in a portal. Some examples of portlet applications are email, weather reports, discussion forums, and news.

Consider dashboard environment. The portlets that are loaded in dashboard may be based on ACL data. Lets go by a scenario to understand this problem better.

Scenario: We need to create a dashboard where we have a button in tool bar of dashboard. On click of that we need to reload data of portlets. In that case, what we shall do is this,

Problematic Solution: We may get instance of all the portlets (registered in some kind of Map or Session manager) and then invoke corresponding portlet’s refresh method. For this we may intelligently use the help of Interfaces. But think if prototyping languages like javascript are so strict about that. Answer is NO. Even otherwise, if we deeply think about the programming intelligence, we would end up in restricting the flexibility of Portlets or any module. We need to communicate properly to all the other teams that we would be using so and so methods to refresh. And  we need to maintain stack of documents to know which object has which method to refresh.

But, as devolpers should we think like this? again No. We will have to adopt a methodology that totally decouples the portlets or modules in this whole game. But how is that  possible?

Optimal Solution: I hope we all are aware about Producer and Consumer problem. Where consumer will be subscribing to an interested topic and producer will be producing messages to that topic. Yes, its a JMS kind of implementation we have to do to decouple the portlets / any system. This strategy can be used widely for any of your systems based on its demands. I used this methodology for alteast 2 of the products I designed so far.

Example of Implementation: For our example I used ExtJS 4.1 based portlets. I picked the portlets example of ExtJS library and then implemented a Message Driven Framework for UI (MDF-UI) and solved the question I put in above block. This implementation totally decoupled the portlets and even my other modules where all my events are published as topics and interested subscriber portlets  will respond based on the topic and message.

Note: You need to know few things about ExtJS to understand this example easily

MDF-UI  Blocks:


Above is the representation of components used to create MDF-UI in ExtJS.

Logger: is used to printing any messages in to browser console.

Constants: is a directory used to maintain all TOPICS

Manager:  is a Lookup Index where we can use it for storing any components object to it. It is not used in this framework directly, but still thought of sharing it. You can use this to register all UI components loaded in the system.

NotifierMap: is extension of Ext.util.MixedCollection where I have implementation for how to use it to easily manage all registered Producers and Subscriber informations.

NotificationManager: is the brain of this framework where we use this to register / de-register producers and subscribers along with the topic.

IPublishedMessage: can be used as Mixin where it is used to fetch messages for specified topic

INotifier: is a Mixin where it is abstract implementation of Notifier.

INotificationLsnr: is a Mixin where it is abstract implementation of Notification Listener.

AbstractMessenger: is a sample implementation of MDA-UI

How it works:

Once the UI / Portlet compoent is loaded the initComponent method will be called Ext. There, I am subscribing the same object by calling NotificationManger via INotificationLsnr mixin with the relevant topic. Like wise, any notifier buttons or components will have INotifier mixin with the topics. So, whenever there is an event, the notifiers will send a message to the NotificationManger which in turn will iteratively call the notified methods of all Subscribers with the message.

Download Source: You can download the sample code here or you can visit here to look at the working demo. Codes are very simple and self explanatory. You can look at them and then post me if you need any clarity on that. To set up your environment, simply download the source code and extract to your htdocs / webapp folder of your server and call http://localhost/works/extjs/mda/index.html. You should see the app in action.

Learning Framework: You should open /works/extjs/mda/ux/messaging folder to see Ext.ux.messaging.* components.

(Warning: If your browser is not loading the app, please try refreshing it once. I am still working to solve the Ext.Loader issues. 😦 )

Feel free to download and use this framework. I would be more than glad to explain this more if you someone is looking for 🙂

Implementation Spotlight: Telensa

Rising energy and maintenance costs due to aging street lighting equipment are some among many of the reasons local authorities are choosing to invest in PLANet — ‘Public Lighting Active Network’ from Telensa. Using a robust Ext-based user interface to control up to 150,000 lights wirelessly, PLANet from Telensa can measure each lamp individually and switch on any combination of lamps within seconds. Get a unique insight into the development challenges faced at Telensa using Ext JS as their front-end of choice.


A typical readings page — supply voltages are recorded by every telecell

We needed to choose a library that was consistent in the way that it presents information to the user, but also consistent in the way that you code using the library.

Tell us a little bit about PLANet and your goals for the application.

PLANet is a street lighting telemanagement system, for remote control and monitoring of street lights. Telecells are installed on street lights as replacements to photocells. These establish wireless connection to a base station, which is a central radio that can also be installed on a street lighting column. A base station can accommodate up to 10,000 telecells over a ranges of 2-3km (urban) and 5-8km (rural). Numerous base stations make up a single system.


PLANet System status page

Base stations connect over regular IP network links to a central system, which runs the overall system. The central system is also a web server and provides the web based user interface. Because of the nature of the system and its eventual possible use by local police, fire departments and authorities, the main challenge throughout has been focused around performance, robustness and fail safe mechanisms.

Efficiency and CO2 reduction benefits

PLANet gives street lighting operators tight control of their lights which translates into a highly energy efficient system – the lights can be programmed to switch on only when needed depending on the time of day, the day of the week, the season, the light level or even the occasion. How much of an energy saving this could make will depend on how aggressive the lighting policies are, but we estimate that using PLANet could help reduce a local authority’s street light energy consumption by up to 40%. This is not an insignificant number when you consider, for example, that the annual energy consumed by all of Europe’s street lights is estimated at 35TWh representing some 1.3% of all electricity consumption.

Why did you choose Ext JS?

Given the wide range of JavaScript libraries available it was important to choose the right one. We needed to choose a library that was consistent in the way that it presents information to the user, but also consistent in the way that you code using the library.

With all Ext components extending the ‘Observable’ class we had the ability to write consistent code in an event-driven manner, much like writing a desktop application, not easily achieved with other libraries. What’s more is that we knew it would work cross-browser, again something not easily achieved that saves countless hours on large projects.

The PLANet application is extremely feature-rich. How did you manage the UI code complexity?

Most PLANet pages make good use of the Ext grid component. In fact, the grid is probably the most central component to the entire application and it was important that we managed the code around this component in as clean a way as possible. Because of the number of columns, each usable multiple time across many grid instances, we collected together all the column definitions into a central file as to only define them once, but use them multiple times. We did this with all fields across the application, including grid columns, text fields, HTML fields and combo boxes. To make the process of changing multiple fields easier and less error prone, we decided to generate the field definitions from the database. This means that each field is defined in the database, before running through a UI build process to make it into a JavaScript file that is included in each web page. Using this process we can manage the generation of UI fields from the database, which means we can control system upgrades from the DB in the future.


Any single street lamp or configured group of lamps can be switched on within seconds

What other techniques did you use to achieve consistency throughout the UI?

Despite significant use of the database to generate UI components, we also extended the grid in other ways to provide state saving, filtering and export functionality.


Custom extensions for state, filtering and export

Each grid can be exported to CSV, taking into account current state and filtering. State of the grid is saved upon each change and when the page is unloaded. In addition, each grid layout can be saved to the database using a simple drop down menu. Filtering is made easy through the use of Ext.Window, with different filters appearing based on the column data type.

What features could we add to Ext to make building a rich application like PLANet easier in the future?

We have found that as we expand the way we want to work with the library, the library is expanding to meet our needs, reminding us why we chose Ext in the first place.

Once an application gets over a certain size, and customer releases become more frequent, the burden of testing the application starts to take its toll. An Ext supported test suite would save huge amounts of time. The current problem of test suites with Ext is being able to reliably predict the automatic ids that Ext generates for page elements. Test tools are beginning to implement support for CSS selectors to overcome this problem, but few currently exist. Ext could provide better documentation on how to build better test cases with Ext so that more time can be spent on development rather than testing.


Lamp Types — dimmable and non-dimmable street lamps are supported

Do you have any advice for developers using Ext for the first time?

Ext can be used by Web Application developers who are familiar with HTML but may have little or no experience with JavaScript application development. If you are starting to build a new web application, or you are revamping an existing application, then take your time to understand the basics of the library including:

  • Understanding the major UI components (grid, form, tree etc)
  • How to integrate your existing data with Ext
  • How to use Ext Layouts
  • The Ext Component Model

Of course, there is only one real way to learn, and that is to get on and do it!

Final thoughts?

As we move on to what is our third major release of PLANet, we are starting to develop with Ext in new and exciting ways. We are loading JavaScript code dynamically from the server as part of a wizard for controlling switching programs of the street lights. We have found that as we expand the way we want to work with the library, the library is expanding to meet our needs, reminding us why we chose Ext in the first place.

%d bloggers like this: