In our application we sometimes have to make minor GUI modifications for different customers:
- One customer has an input field the others don’t have.
- Another customer has all default fields but one of the optional input fields is mandatory.
- A third customer has the default fields, but one field has its caption changed
- A fourth customer has several new input fields and one existing multiline input field has to be changed to a single line input field (to make room for the new fields)
- …
(Note: Although these examples might sound awkward, those are things our customers asked for)
How do you handle these cases?
- In general
- In Java/Swing
Currently we designed the form in the most common way. At runtime we make adjustments like hiding, resizing or repositioning fields. On input validation we validate the contents depending on the active customer.
This issue has three aspects: form layout, database storage and configurable business logic.
Configuration driven form layout
A flexible approach to form layout could be achieved by moving the layout to a descriptor file. Three GUI toolkits that support this are QT, WPF and XUL. However, AFAIK Swing does not directly support this capability. QT Jambi does allow you to use QT on Java as an alternative to Swing and QT 4.5 is going to be available with LGPL licensing. This is not a pure-java solution, but may be a possibility if this and the attendant re-write of the UI code is acceptable.
The advantage of the configuration driven form layout is that the customisations can be made without having to maintain a separate build for each customer, so even if you have an incumbent code base, you may wish to examine whether there is a business case to adopt such a toolkit vs. maintaining multiple customer-specific builds. However, for a compiled language, you may still need to set up some sort of plug-in framework for the generated form code.
Configurable database storage
This is more complex. You can do this in three ways, which have their pros and cons.
The first approach is to have a series of ‘user’ fields on the table, such as ‘User1’, ‘User2’ etc. Configured fields on the forms can be mapped to these fields – and a generic user field mapping facility should not be difficult to implement. This is the most efficient from a database query perspective but suffers from the limitation of a finite number of possible fields. If you have fields ‘User1’ to ‘User20’ you can only support 20 user defined attributes. Also, they will have to be nice, wide generic varchars, so you will get no type safety from the database.
The second approach is to have an attributes table hanging off the entity. This doesn’t give you type safety, but it does let you have as many attributes as you want. Building a generic handler for this is also quite feasible but the query performance will be affected as you do multiple joins against the attributes table.
Persist the user defined fields in an XML blob. This has little to recommend it, as it makes the data harder to access through the database. However, I have seen it done.
Configurable business logic
This is a much more thorny issue. Without adding custom code and changing your build, you have a few options for doing configurable business rules: Rule engines, scripting languages or a set of standard on/off features such as mandatory fields.
Rule engines: You really have to design your application from scratch to use these, and they have their own limitations and foibles. ILOG, The incumbent in this field, is also quite expensive. For java, JESS might be an option.
Embedded scripting language: By adding an interpreter for Jython, Groovy or some other JVM-friendly interpreted language, you can write plug-ins for the system without having to issue a new build. Some testing workload will still be incurred, but this might be a maintenance win overall.
On/Off configuration for features. This is the least flexible option, but is relatively simple and adds relatively little in the way of external dependencies and licensing costs. It may also be your only choice if you’re trying to retrofit configuration to something that started life as a bespoke application.
None of the Above
If the answer is ‘None of the Above’, you’re probably stuck with custom builds. In that case, make a plug-in architecture for the forms so you can at least isolate the customer specific items into a separate module.