actifsource: New wizards needed

This week I created two new wizards for importing and exporting the ecore model. If you ever created an eclipse jface wizard you know there are a lot of things to do.

- Create the wizard class
- Create the wizard page and add them to the wizard
- Initialize the values of the wizard and it’s pages depending on selection
- Implement the code to update status message
- Defining when a page is complete
- Place the wizard page control
- Connect the page controls that depends on each other
- Remembering and Storing the settings from last wizard usages
- Setting the initial focus control
- Defining the perform finish code

Since these tasks are always the same for all wizards we decided to use our actifsource templates to generate the wizard classes. You may notice that some of the tasks above may be done by super classes. For example we can setup the layout manager, define the page complete state and collect the status messages from the page control interfaces. We also may set the focus to the control containing first undefined value. But all these tasks don’t require the concrete types of the values. When we come to the initialization, finish and settings management code, we have to start writing a concrete subclass for this wizard and these are the classes we generate. The templates automatically create the fields for accessing the concrete wizard pages, allowing access to the specific getters and setters not on the page interfaces. I also defined the dependencies of page controls in the model. This way the code for connecting the controls with each other is created by the generator. Code that has to be handwritten is placed in protected regions. It’s the code for initializing, storing the settings, updating the status message and performing the finish action, but this time I don’t have to create the things like field for accessing the wizard page and the initialization method for each page. I’m more or less forced to put the code in the right places. The structure of each wizard implementation is kept clean.

Now all we have to do is to create a wizard instance in the model and define the pages with their control and connect them. Afterwards the generator creates the whole skeleton and we simply have to fill out the gaps. If we decide to rename a wizard all class-, field- and method names coming from the model are changed by the generator.

Look at the model:

I defined a Wizard-Class which contains WizardPages containing inputfields (package-selection, filename-selection, etc.). Each inputfield has a name and uses a fieldeditor (page controls) that may define other fieldeditor as dependency. When the fieldeditor has a dependency you must define a dependency from that to an inputfield to another inputfield using the required fieldeditor. For example I can create a package-field which is restricted based on the selected a resource folder. After defining some name, titles and page descriptions I’m ready to go. Further work that may be done is writing templates for the fieldeditors.