Redesign Wizard API - Requirements
$Revision: 1.1.1.1 $ Jiri RechtacekAbstract:
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 supported use cases
List of usecases for which must be theWizard 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.
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
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.
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.
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.
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.
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