Redesign Wizard API - Requirements

$Revision: 1.1.1.1 $ Jiri Rechtacek

Abstract:

There is a list of requirements that were accumulated from various issues in our bug tracking system and also from Sun internal meetings with developers building own wizards.

General basics and constraints of Wizard API

The Wizard API must satisfy at least these requirements for acceptance:

• well-documented contracts, credible and solid
• support for wizards shared between several modules
• don't force instantiate of all panels there's no need, to keep good performance
• support for long-term tasks
• good responsiveness during go through panels

The general basic is also separation the data, control and view parts.

The supported use cases

List of usecases for which must be the Wizard API designed. (Note: the list of use-cases is under construction, it's out of the question that a use-case can be removed and other added.)

• U1: creating of new simple object (in some mounted filesystem)

Easy, one way from start page to finish. Set of steps is known before and depencensies each other are known too, Internationlization Wizard for example.

U2: creating a more complex object, other modules can add other features which have to be customized

More modules provide a set of features and releated configuration page which will be a part of sequence of steps. Each module can declare own page to publish. It also asks some control which page is finishable or not, it adde some kind of dependence between pages. Some aspects were solved in TemplateWizard

U3: creating new object with a property which decides next sets of properties to be customized

The value of a property on a configuration page decides, which type of object or type of service will created or customized. The set of steps cannot be known before the property is entered, its value must be reflected and visualized in wizard's control panel, i.e. in pane which displays the steps. Also the time, when the wizard can be finished, could depend on this value. It requires support for enable/disable the step-control buttons on-the-fly.

U4: To configure a service provided by remote system, customize it and integrate in local system

The wizard have to connect in remote server or perform long-time task, a good responsiveness is required e.g. progress bar with the Cancel button or any other way how to keep an user informed.

U5: configuration of a new service asks large amount of steps, should be summarized before finish

Well known example is such as Install shield, amount of settings is summarized at the end of wizard before finish it. Of course, it asks a support for summary page.

U6: configuration page provider wants notify the user about suspected places (i.e. by color, bold font etc.) when validation fails

The client, provider of page, should be able to replace the page when validation failed and the user is returned back. The replaced page could contain e.g. an alert label on the bad-filled field.

U7: platform user wants change the skin of wizard's l&f

It is use-case which have been not asked yet but could be useful for branding. It could be in mind and build in API if possible and be lightweigh too. It won't be forced.

Extend new API with aspects from Templates wizard

TBD

How to handles templates with new datasystems?

TBD