How do you handle form customizations for different customers?

Question

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.

Answer 1

I'm not sure what type of application this is, but when we get conflicting feature requests, we typically branch off each client's version, and include only the relevant code in each branch.

Are you using any type of code control / versioning system? SVN is what we use, and it lets you update each branch as you make changes to the main code, so the code is never out of date.

Answer 2

There are a couple of different ways to go about this. However, it's very situational dependent.

1. Instead of adding different customer logic in the same screen, have a different screen per customer with a default one used by everyone.

2. Custom builds or customer branches. Although this can get pretty complicated.

3. Do exactly like you've done and embed customer specific logic in the screens.

4. Use some type of rules engine to drive your interface.

Answer 3

I would do something similar to the FORMS creation screen inside of MS Access, allow the customer to add/remove/modify and set inputs on their own. It would also allow them to set which fields are mandatory and which are not. It would mean more work on the front end for you, but less on the back.

Answer 4

I would suggest using some sort of plugin system. For each customer, just create a plugin that modifies your application's UI and have it loaded at startup. I'm not a Java programmer, so I'm afraid I can't post any specific code snippets, though.

Answer 5

I can think of 4 approaches:

1. Don't. Yeah I know it's too late now, but if you can get away with it, always sell a standard product.

If that is not possible...

1. Build a feature matrix, where each customer can define its own requirements by ticking boxes (Field disabled, Present Mandatory, Present Optional etc). It limits how you can present your info in the UI - you tend towards a simpler design, but it is scalable and flexible.
2. Have a Custom page per customer, where each page supports itself in terms of business logic and validation. Perhaps you can get away with 3 or 4 variants that are offered to each customer.
3. Branching. If you do this, make sure the customer pays because it's an expensive PITA.

Answer 6

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.

1. 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.

2. 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.

3. 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.

1. 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.

2. 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.

3. 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.