A wizard hierarchy allows multiple wizards to work together. For example, one application of wizards is software installation. Generally, an install wizard would be designed to install a single product. It would be nice if multiple products could be installed from the same wizard. A cdrom with four products on it could be installed from a single wizard in the root directory of the cdrom that connects four single product install wizards into one user experience. The wizard hierarchy preserves the user's ability to use the single product install wizards, as well as provide a multi-product installation solution described above.
On the server side, the wizard hierarchy works by instantiating a WizardState object for each wizard archive in the hierarchy. Each WizardState represents a wizard, and facilitates access to that wizard's archive file. There is also an ArchiveReader object associated with each archive in the hierarchy. The root WizardState object is the WizardState associated with the wizard archive that was executed. The other wizards (the ones that were not directly executed) are considered child wizards. Remember that the only connection between the server and the client is between the root WizardState object and the WizardTreeManager. Route objects are used to send messages to the appropriate WizardState objects.
On the client side, the hierarchy is a little more complicated. The only wizard client tree that is loaded comes from the root wizard archive. The WizardComponents within that client tree can request subtrees for display from the child WizardState objects. These requests are actually sent to the WizardTreeManager and fulfilled by the WizardState's ArchiveReader object. The subtrees can be parented by any of the WizardComponent objects in the wizard client tree. Once the subtrees are added, they can be navigated and displayed as if they were part of the original client tree.
Each panel has a Route object that will route server messages to the correct WizardState object. In this way, the user is oblivious that multiple wizards are being used to perform the task at hand. A single user experience guides the setup and actions of any number of wizards.
The structure of the wizard client tree is very important to the success of multiple wizards cooperating in this manner. Nodes must exist in the parent wizard to provide a hook to which the child panels can be attached. The panels from the child wizard that are to be displayed in the parent wizard must be children of a node. The hierarchy is created through a node in the parent wizard reading a subtree (a node with children) from the child wizard(s) and setting itself as the parent of the subtree.
The links shown in dotted lines are created at runtime.
Only nodes that are direct children of the client tree root can be read as subtrees from the archive. Individual panels or nodes that are children of other non-root nodes cannot be deserialized directly from the wizard archive.
Last modified: Fri Nov 25 16:48 PDT