Design Issue:

Motivation:
There are as many as 37 config items; each config item has different
fields and each field entry has different set of validation rules. The
config items are sequentially arranged and have dependency between each
other (the next config entry depends on the values provided to the
previous config entry). We need a mechanism to configure all 37 config
items.

One approach is to have a Wizard kind of set up to configure the items.
That is, display each config item and its associated fields in separate
screens; when user chooses next, based on the current input we can
generate the next config item.

But using a Wizard will require 37 screens (one for each config item)
and if the GUI is to be generated with a tool (for eg: Netbeans) then
using 'Generation Gap' pattern would double the classes required 37 * 2
= 74 classes! Besides if config items increases that would increase the
number of screens which in turn would double the classes required; this
obviously is a class explosion!

I guess this is a generic issue and I'm wondering if there is any
alternative or a design pattern to address this.

Thanks, Soms.

====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)