Designs act as the starting point for the development of software, so DesiGen can generate code based on your design. It is this combination of design and code generation that we think makes DesiGen such a powerful tool.
The purpose of code generation is to give you a quickstart to development. Assume that the generated code will need to be customised. Hopefully the design that you created detailed most of the customisations necessary. However, in agile software development, it is often preferred that we deal with the small details later, especially detailed business rules. As a result, those details may not have been known at design time.
Generation takes the contents of the template on which each artefact was based, passes to it the data structure with which it was associated and the properties you have defined against the artefact and combines them into an output. Think of generation as moulding the details from the data structure and artefact properties into an output whose shape is defined by the template.
Code generation is generally intended to be a one-time operation. DesiGen is a passive code generator - in other words, there is no support for retaining customisations you make to the output of generation. The generation performed always uses the template as a starting point, so if you regenerate an artefact then any changes you made to the output between generation runs are lost.
For safety, the default generation behaviour of a new artefact is one-time. However, if you have created your design in such a way that an artefact will not be (or has not been) modified, then it is safe to regenerate it. Therefore, other behaviours are available for your use.
The available behaviours are:
Never. This artefact is never considered for generation, and no output is produced.
Only Once. This is the default; the tool remembers when generation is performed, and will not repeat it.
Regenerate Once. This behaviour generates the artefact on the next run, irrespective of whether it was previously generated. Any customisations in the output are lost. After generation is successfully completed, the behaviour is changed back to 'Only Once' to prevent further regeneration.
After Each Change. If changes are made to the properties of the artefact, it is regenerated on the next run. Any customisations to the output file would be lost.
Always. Generation is performed on this artefact on every generation run, overwriting any existing output, and losing any customisations.
Remember that behaviours other than 'Never' and 'Only Once' could result in you losing any changes you have made to the generated output, so use other values with care.
Code Generation Tips
Splitting your design to make use of regeneration is possible, by splitting the solution into more parts. As an example, you could generate two partial classes, one of which is intended for regeneration and the other intended to house customisations. However, this is likely to overcomplicate your design. Generally, it is better to keep your design simple, and try to ensure that you run the generation process only after the design is completed (and ideally checked/discussed with another team member, perhaps as a design review.)
Agile software development trades overall development speed for the ability to change direction. Be careful with the trade-off between overcomplicating your designs and making future change easier. Whilst it can feel wasteful to manually change code that was previously generated, it is a necessary part of incremental and evolutionary software development.
Think of the output of code generation only as the starting point for development, not the end of it. It is dangerous to try to change templates to cater for every possible eventuality, in the hope that you can generate a perfect output that needs no customisation. If you start to think that way, you will quickly fall into the generation pit of failure. You will forever be writing and refining templates instead of delivering working software. Carefully weigh up the cost of each customisation to a template, being sure to carefully assess the future maintenance cost each time you add complexity to that template.
Active code generators can lead you to the generation pit of failure. Remember that DesiGen is not intended to be an active code generator. Asking for it to become one, or expecting it to be a future feature, will lead to disappointment.
Simple templates are much easier to maintain than complex ones. Consider creating a new template if you identify a new scenario/pattern that is to be supported, rather than making a single template very complex.