Recently, I am responsible for a project to design a web application which automates many operational tasks that are carried out manually now.

One of the challenges for this project is the dynamic nature of the user interface.

  • Based on different types of the client and the different features the client subscribes, the user interface needs to display different widgets.
  • It’s expected that the types of clients and client features will undergoing constant change in the future releases.

Traditionally, those requirements will be addressed by:

  • Build in the logics in the user interface layer, specifically in JSP page with JavaScript.
  • Update the UI logic as the requirement changes in future releases.

The drawbacks are obvious. We end up with JSP page cluttered with business logics. Hopefully, with the help of the carefully designed tag libraries, the page won’t get too ugly. Nevertheless, the constantly modifications of the JSP pages for each release require significant development and testing time. Not to mention about the difficulty to test and the possibility of screw-up some of the logics.

Carefully examining the situation, I found patterns of the requirements.

For each type of the client, there is a list of client features. For each client feature, a list of properties needs to be captured.

Although the features and properties vary from one client type to another, these two patterns remain. I was able to design a simple data model to reflect those two relationships. Everything that needs to be displayed in the GUI can be configured in the database first.

For example, a client feature requires three properties, one String value, one Boolean value and one chosen from a list. In the database, I can put three records for those properties storing their label name, type (text, checkbox, and select list) and other cosmetic information like length of the text box.

Then, I have the back-end server reads those “meta” data and feed them to the GUI. In stead of hard code the logics, the GUI use JavaScript to process the “meta” data and generate the layout on the fly based the “meta” data.

For the above example, the JavaScript in the GUI will iterate through a list of three java beans, each containing the label, the type, the length and other cosmetic information about the widget and create the widget accordingly.

It worked nicely to resolve the challenges I am facing. I can, in a sense, “program” my GUI layout flexibly by entering different data in the database. Every time, I need to add a new type of client, or a new feature or several new properties, I add a bunch of records in to the database and “Walla”, I have the GUI layout I want.

The advantages of this type of data driven GUI design derive from the simple fact that data is much easier to change than the codes.

In additional to a shorter development cycle, data driven GUI design also maintains the basic patterns (type-feature-properties) I identified since those patterns are coded. It eliminated the need to copy and paste codes, which frequently lead to errors.

The codes are easier to maintain too. As long as I document down the data model, another developer can change the GUI layout as much as he wants without having to understand my GUI codes.

Extending the thinking to larger extend, whenever a strong repetitive pattern is found, we should think about ways to break out the “fixed” (doesn’t change much over the time) logics and the “flexible” (frequently changing) logics. Implement the fixed logics in codes and represent the flexible logics in data, either in relational database or in XML format. By doing so, we get a stable and yet flexible architecture, well prepared for the future dynamics.