In generating code, MetaFactory uses a strict separation of concerns between the (enriched) data model and the code instructions. The code instructions require the data and metadata of the model to turn its abstract code into the real application code that satisfies your requirements. You are in full power of what metadata is defined and how it is handled in your code instructions, which is what so greatly distinguishes MetaFactory from other code generators.
The above mentioned separation of concerns is reflected in the project structure of MetaFactory. The root of the project contains the file metafactory.xml, which is used for global project configuration. Next to this file there should be ‘pattern’ folder with the pattern.xml file and a ‘model’ folder with the model.xml file. The chart below illustrates how these components interrelate.
Next to the required components of metafactory.xml, model.xml and pattern.xml, MetaFactory will also look for an optional file local.properties – in which you can define machine specific properties. Code instructions are viewed in the chart as fully contained in pattern.xml (which is fine for a simple project), but can be spread over many more files through the use of includes. Read more about XML code instructions here. Also note that although not always required it is recommended to use snippets for your code instructions. More on the benefits of snippets can be read here.
In the next sections we elaborate on the background and functionality of metafactory.xml, model.xml and pattern.xml.
The metafactory.xml file takes care of the global project configuration. It links to the soure files of your model, pattern and snippets. It also sets the root output path of the generated code while distinguishing between Java, XML and generic files. Default behaviour for code generation can be defined inside the <businessStyle> element. If you do not include this element it will be automatically generated with default settings when you run MetaFactory.
You setup the latter file once and will likely not work much with it afterwards. This is different for your model and patterns, which are at the heart of the code that will be generated. There is a clear seperation of responsibilities between them. The patterns – of which pattern.xml is the base compenent – constitute your code as you would normally write by hand, but instead abstracted to serve all entities. The model fills in the blanks of the pattern in various ways. Read more about that below.
The model.xml file contains all data objects (entities), which can be grouped in various packages. Each object can have attributes and references to other objects (the equivalent of Java’s entity properties). This way your pattern can read out all entities and generate code for each of them, depending on how you constructed your logic on what to do with the datatype of your nested attributes and references. You may however need more intelligence than just data types to create effective patterns. This is where the option of adding metadata to your model – either on object or attribute/reference level – comes in. Metadata is specified in your model as ‘properties’, which in the file might look like this:
<attribute name="streetName" type="text" notnull="false"> <properties> <crud.textarea.rows>3</crud.textarea.rows> <crud.vieworder.dialog>4</crud.vieworder.dialog> </properties> </attribute>
In the latter piece of code ‘crud.textarea.rows’ controls how big your textfield should be, whereas ‘crud.vieworder.dialog’ controls the position of the attribute on the dialog screen. Do note however that properties are completely free to define yourself. Nothing is predefined by MetaFactory and properties don’t have any meaning when there is no pattern that actively reads them out. Think of it as ‘toggles’ that you introduce to help your pattern acquire the necessary input data to control its behaviour. Also note that we used numbers in this properties example, but you can use any piece of text. It is the job of your pattern to properly process whatever you choose to define there. The complete set of details regarding model use can be found here.
The pattern.xml file is the base location for your code instructions (you can import other patterns there). A pattern is an abstract version of your application code, using an xml element structure to define java classes, methods (called ‘<operation>’), class/object fields and so on. You can write all code instructions in pattern.xml, use includes (refering to other xml code instruction files) to better structure the information, or gain more advanced templating features by using Freemarker or Velocity snippets. Note that this only holds for Java generation. If you choose to generate other languages then MetaFactory doesn’t provide an xml structure (yet) for code generation, but you can still define all the structure of your code inside a Freemarker/Velocity snippet that you use straight in the <body> element of your pattern.xml. The complete set of details regarding code instruction use can be found here.