Wizard as a Dialog

In an RCP application, I had these requirements for a Dialog box:

• OK button should not be enabled until all the mandatory fields are filled
  
• Hints for probably incorrect data (The email id grprakash+eclipse@gmail.com "looks" like a wrong one) These should not stop the user from pressing OK
• Progress bar should be shown for long running operations (clicking OK, "check for user id availability", etc)

I was thinking on how to handle all these in a Dialog and something flashed in my mind - JFace Wizards. All the above requirements can be easily done if I use a Wizard. The Finish button is disabled when we call setPageComplete(false), we can show warnings and still allow the user to finish and by calling setNeedsProgressMonitor() & getContainer().run() we can show the progress bar in the UI as well. But there are two small issues to be handled when we use the wizard.

• The first one is to get rid of the Back and Next buttons. We are lucky here because JFace will not show those buttons if there is only one page in the wizard
  
• The "Finish" looks odd and should be renamed to "OK" or "Submit. This can be done by subclassing the WizardDialog:
  

WizardDialog dialog = new WizardDialog(shell, wizard) {

@Override
protected void createButtonsForButtonBar(Composite parent) {
super.createButtonsForButtonBar(parent);
Button finishButton = getButton(IDialogConstants.FINISH_ID);
finishButton.setText(IDialogConstants.OK_LABEL);
}
};

Now with the util method, I can enable/disable the "OK" button, reflecting the status of the UI items.

Related:
Util method for Wizard Pages
JFace Wizard Guidelines

Handy util method for WizardPages

Consider this familiar New Java class wizard.


It has to keep track of the status of the source folder, package, enclosing type, name, ... When ever there is a change in these fields, the WizardPage's status has to be updated. The algorithm goes like this: find the most severe status and update the wizard page with that status. This is a very common operation can be applied to any WizardPage. So I've written a helper method which I usually use it in almost all of the WizardPage I create. Let me know if it can be improved

public static void applyStatus(WizardPage page, IStatus[] statuses) {

IStatus severeStatus = statuses[0];
for (IStatus status : statuses) {
severeStatus = severeStatus.getSeverity() >= status.getSeverity() ? severeStatus : status;
}

String message = severeStatus.getMessage();
switch (severeStatus.getSeverity()) {
case IStatus.OK:
page.setMessage(null, IMessageProvider.NONE);
page.setErrorMessage(null);
break;
case IStatus.WARNING:
page.setMessage(message, IMessageProvider.WARNING);
page.setErrorMessage(null);
break;
case IStatus.INFO:
page.setMessage(message, IMessageProvider.INFORMATION);
page.setErrorMessage(null);
break;
default:
if (message.length() == 0) {
message = null;
}
page.setMessage(null);
page.setErrorMessage(message);
break;
}
}

JFace Wizard Guidelines

During Eclipse Plugin Developement training, I always end JFace Wizards session with these guidelines:

1. Wizards should be aimed for minimal user interaction
2. Wizard pages can be filled with meaningful defaults
3. When a Wizard is shown it should not contain any errors. They should appear only after a user interaction
4. Present Errors/Warnings in the tab order of the fields
   
5. When a task is split into steps, a wizard page can model a step and shouldn't be doing more things
6. Don't create pages that needs scrolling. In general if a wizard's height is greater than its width, probably it needs a review
7. Total number of Wizard pages should be ~ 5

Once when I finished explaining them, one smart guy said: "Have you ever looked at the New Java Project Wizard?". True. The first page of that wizard doesn't comply with the Guideline #6. These points are not official standards, mere guidelines by me, but still I think they are good. So what is the problem with the New Java Project Wizard and how can it be better?

The options in the first page falls into three categories:

1. Resource: Project name, location & working sets
2. Compiler: Source folders
3. Runtime: JRE & Execution env.

Ideally the first page should just give the resource related options and the others can be pushed to second page/elsewhere. Since the second page allows the user to configure the JRE, source & binary folder, I guess we are not loosing any functionality if we get rid of those options. If the first page is cleaned up to have only resource related options, this is how it would look like:




in contrast to the current: