1.6. MetaFactory process overview

This story is basically an explanation of the Powerpoint presentation ‘Ontwikkelproces01.ppsx’. For a download Downloads.

1.6.1. Conventional development process

1. A typical conventional development process starts with a design, which produces de definition of a number of objects. The term ‘object’ is used here in the general sense of representing ‘something in the real world’.

2. Next step is to write source code to implement characteristics and behaviour of the object. This is done manually, object after object.

   If there are many objects, it is very likely that many of them have similar sets of characteristics and behaviour. For instance their Create-, Read-, Update- and Delete- screens will (hopefully) act similarly. Their REST controlers are almost identical.. and so on. So a lot of programming has to be repeated for every object again.

   Another aspect is that the latest insights (about required functionality, about programming discipline, readability of the code) are being frozen in the source code. If the insights change and you want them to be implemented consequently, you have to do a make-over for all the previously created sources.

3. Compilation creates executable code that is ready to run on your machine.

4. Next step is to design a database. Using the object definitions from step 1, a datamodel is created and

5. A database is generated. Now you should have a working application.

6. Last but not least you need to develop test scripts if you want to assure that the application is thoroughly tested before it is taken into production.

1.6.2. Development with MetaFactory

1. Fortunately we start with a design too. The objects are collected in a MetaModel.

2. MetaFactory generates source code for the objects, based on Code Instructions. These are sets of instructions, which control the generation process.

3. The source code must be compiled, just like in the conventional way.

4. With a special Code Instruction MetaFactory will, based on the MetaModel, create a database generation script. This makes generation of a new database as ‘easy as a breeze’.

5. The same is true for testing. If a suitable Code Instruction is available, MetaFactory creates test scripts.

This technique opens the door for a lot of flexibility:

• When an object has changed, source code and database can be generated in one run. The code and the database always stay synchronized. And the test scripts are updated too.

• If you change a Code Instruction, all sources, based on that Code Instruction are updated. No make-over for all sources any more.

1.6.3. Diversify

The situation depicted in Section 1.6.2 is rather simple. With a plain Code Instruction all generated sources will be similar, except for some object-bound matters. For most projects this will not be sufficient.

But don’t worry. Our toolbox is far from empty.

1. Metadata

   You can enrich the MetaModel with metadata. These control the generation process of the Code Instruction. So with different metadata, the same Code Instruction can generate different stuff.

2. Snippet

   A Code Instruction is written in XML, which is not a programming language and lacks all the fancy contructs a programmer may need. However, these programming facilities can be injected into a Code Instruction in the form of one or more snippets.

   A snippet is a piece of programming code, written in Freemarker or Velocity. Besides the usual stuff like variables, conditions, loops, et cetera, there is an huge library of functions available for snippets.

   With snippets a Code Instruction can generate all the generic (say: default) functions for the objects.

3. Hook

   But there may be a need for project-specific behaviour. That’s what hooks are for. They are project dependent snippets. It is called by a snippet and can add extra functionality or change the behaviour of the snippet. In general a hook modifies the output of the Code Instruction.

4. Feature

1.6.4. Reuse

Whether you are developing for a car dealer, a bookstore, a tools rental or for a financial service, every time you are confronted with a numer of objects or entities with characteristics that must be stored in a database and be maintained. These objects have a lot in common, across projects, across companies, even across branches. Normaly the common stuff has to be coded over and over again for each object. But in the MetaFactory way this is done by generating with the same Code Instruction(s).

A Code Instruction, once built, can be used over and over again. This is the real strength of the MetaFactory way.

1. Well designed and well built Code Instructions can be collected in libraries.

   MetaFactory is developing standard libraries with basic Code Instructions which are useful for almost every project.

2. Reuse

   For a specific project you can create specific Code Instructions by writing them yourself or by copy-paste-modify from other projects. But the real benefit is in using general Code Instructions. Assisted by hooks for project specificy.

1.6.5. Building a Code Instruction

How to create a Code Instruction?

1. Start with hand written code. It may be manually coded based on your design, copied, stolen or whatever.

2. Identify the logic that is suitable for use in general situations. Don’t bother about the details and specifics, that’s for later. Create a Code Instruction, based on that general logic. Now there are some facilities even to generate Code Instructions from handwritten code.

3. Run the generation process.

4. Examine and evaluate the generated code.

5. If the results are not as expected, modify the Code Instruction and run the generation again until you are safisfied with the results.

1.6.6. Metadata - Interaction between MetaModel and Code Instruction

As is clear from Section 1.6.3 during generation there is an intimate interaction between MetaModel and Code Instruction. Metadata do play a key role here.

Fig. 1.8 MetaModel tree and Metadata

Fig. 1.8 shows the structure of the MetaModel file metamodel.xml. MetaFactory allows the addition of metadata to every level of the model tree. For every Package, Object and Attribute or Reference, any number of metadata can be defined.

You are completely free to define the names of the metadata as well as how to use them in your Code Instructions.

At generation time a Code Instruction iterates through the Model and reads the metadata. Depending on the metadatum and its value the Code Instruction may instruct the generation process differently.

An simple example: show or don’t show a button

Table 1.1 ‘Save and new button’

Visible	Metadata	Visual
No	<crud.save.and.create>false</crud.save.and.create>
Yes	<crud.save.and.create>true</crud.save.and.create>

For a single MetaModel many Code Instructions can be used. And a single Code Instruction can be used by many MetaModels (projects).