Generating Wizard Classes

Today I give you a short insight into the wizard template. I don’t want to show every detail, but you should see what’s possible. For this blog I assume you already tried our tutorials and you know how to create and register a template.

Let’s build a simple WizardTemplate, to generate the main class for each wizard.



As you can see this empty template has an error at the filename line. This indicates that we have to define a filename otherwise we won’t get any output.
On the filename we put the WizardClass-Instance-Package and the Name. Since packages are separated by a dot, I used the builtin function “package2subdirectory” to replace the dots by slashes.



Now let’s generate the signature. Each wizard class should derive from a GeneratedWizard class, which contains non generated methods use by all wizards. I also added a wizardInterface–method to get the eclipse Wizard-Interface (INewWizard, IImportWizard, IExportWizard) from the model.



This will generate a class for each wizard having the wizards name, extends the class GeneratedWizard and implements a specific Wizard-Interface. At the moment this won’t compile, since there is implementation of the abstract methods. Let’s add some more code.
Pressing “ALT+Insert” allows me to add a new linecontext. I want to have a field for each wizardpage, I added a selector to iterate overall pages of the current wizard:



If you ever wrote a wizard, you know pages are registered by the addPages-Method. The generator should create it and add a line for each wizard page. Since there might some setup code to create the pages, I want a creation method for each page:



For the creation method I add a third context iterating over the pages. Using separate contexts I keep all fields and creation methods together. You might choice another way to group the methods based on your companies coding guidelines:



I added a protected contexts for the constructor call, so it's possible to change the generated code to pass additional parameters later. The code in the resulting protected region won't be touched by future generator runs. Finally I added a add-Method to register the page:



Look at the reference to the wizard field, it's the same text. To see that the fieldName is ment, I extract a function using the quick assist (Ctrl+1):




Via copy paste I replaced all other occurencies:



Using more information from the model, I get some thing like this:



As you can see the template is still readable and there are nothing special with one exception, our links to the model. No for-each loops and template keywords between the code.

The same can be done for each wizard page:



The fieldeditor are registered automatically, so you don't have to write the fields, initialize them and finally create each fieldeditor. The logic for creating the GUI-Controls is in the GeneratedWizardPage-SuperClass, it just call the createControl-method on each registed fieldeditor when eclipse request the page control creation.
You might have discovered the line calling the "depencencySetterName", this line creates the binding between the fieldeditors. As I mentioned in the last blogs the binding is used for the package-fieldeditor to only show the packages in resourcefolder selected by the resourcefolder-fieldeditor. This is really smart, you cannot forget to set the bindings, since the model forces you to do define them and the generator does the rest.

I hope this short insight into the templates help you to understand how actifsource can improve your work.