How it Works

This is the technical bit. In short our widgets are built in Flash, we use an application to collate and manage the data feeds that update the widgets, those feeds can be secure and can handle a range of different system feeds.

All that means is that the widgets look great, the data is secure and we can take data from just about anywhere you’ve put it (and that’s the hard part).

Want to know more – read on…

The user logs in so that we can decide which content is available to that person. This means that someone in operations would have access to different widget content to people in marketing, for example. The username and password will be configurable in the database and an administration area for management of widget permissions would be created.

Each widget has an ID. The ID of the widget is defined by the login URL that is configured to be used by the Google Gadget for the content. The ID is used to differentiate content between different widgets, since all widgets use the same session.

Once the user has logged in we need to know what content they want to see in that particular widget. A decision is made in the next step. This decision is stored in a map, along with the widget identifier, in the users session.

Once the decision has been made, the user is taken to the content JSP. An AJAX call is sent to the server every ten seconds requesting data that the user selected in the previous step. This call updates the text and images on the screen based upon the latest data.

The data is accessed on the third party server as an XML feed. We connect to a URL in Java, retrieve the XML and then parse it into basic Java objects. These objects are then used by the JSP pages to exchange the data with the JavaScript on the page and, in turn, update the content dynamically without requiring a page refresh. The data that is stored by these objects is easilly persistable should we wish to store historical data for use in charts etc.

The application is built using a modular framwork that keeps content (display) code away from data processing and persistence. We can swap between HTML/CSS and Flash in the front end without affecting the XML passing etc. We will also be able to swap between any database vendor as required. The application is built as a basic WAR deployment and is hosted on a Tomcat5 server but it will be able to run on any J2EE server and I currently write and deploy it onto Jboss for testing before deploying to the live server.

The application uses a framework called Stripes for mapping actions to content. Layout and CSS is managed in a single file so that changes to look and feel can be applied across the application with ease.

The AJAX and other JavaScript functionality is provided by the Prototype framework so that cross browser compatibility concerns are minimal.

Accessing the third party XML is cached and only updated every 30 seconds regardless of how many clients (widgets) are requesting the data. This avoids us making excessive HTTP connections to the third party when many people are looking at the widgets which would seriously affect scaleability.

All timings and refresh rates are configurable and all widget content can be displayed in other languages as required.