The idea of generating the wizards came up, when Micha had to create new wizards and looked into the other implementations to see how the wizard pages where built there. Since all the wizards where completely handwritten, there was nothing but the coding conventions that restricted us in implementing them. As a result, each wizard does its job a little bit different.
How is this possible? If you think about your own code you will find out quickly, that if you have to implement the same stuff a half year later or give it to a colleague, it will result in slightly different code. A reason for that is, that writing code always depends on the experience of the developer, which grows over the years. It comes the time where code style and coding conventions will be changed, but no one will go through the old code to update.
What can we do against this? One thing is discipline in following company guidelines. But who really remembers all the rules? Some rules are not even written down in a document. Here is where actifsource templates can help. A template defines the structure and limits needed to ensure that things look the same way and ensure that changes will be made in all implementation at the same time.
Okay, let's start. We have the code mess, we want to get rid of. First, you have to find a meta-model, that is common for all wizards, but still different when writing the wizard classes. All wizards have a title, a description and pages. The title and description is always set in the constructor. Each page must be accessible by the finish-method, thus we need to declare a field of the concrete type for each wizard page. These are things normally done by hand. The information will be stored in the model and the translation of the code structure in the templates.
After collecting the information, I started creating a new actifsource resource folder in the existing wizard project and creates an actifsource class named "Wizard":
The second class I needed was the "WizardPage":
The wizard page, again has a title, a description and an inputfield. The inputfield are the different control to be filled out by the user. There are some more classes but I think you can see where this goes. I don't define the field and methods to be generated in the model, I created a simple description of a wizard.
The data for each wizard is also stored in the model, for this I created a model instance of the wizard class:
As you can see this is a really minimalistic model. That is one of the benefits of using actifsource, the model can change over the time as needed. Actifsource supports iterative and incremential development.
By the way setting of the dependency between the resourcefolder and packagename is forced by a decorating property. If you are interested how they work, checkout our State Machine Tutorial.
The next time I will tell you about how the GUI code is generated by using actifsource templates.
No comments:
Post a Comment