/   Model reference


MetaFactory supports both XML (recommended) and Yammel to contain the model data. This document describes the required structure of the file and its child elements. To learn more on how to access and manipulate this file from within your code instructions, please check the Model API documentation.

Model structure

The MetaFactory model file contains a ‘model’ element as root, which has one or more packages that are used to group data objects (entities). Every object can have attributes and references to other objects inside the model, which is equivalent in functionality to Java’s entity properties. Using the model and code instructions MetaFactory is able to generate (‘to MetaFactor’) the code for all the entities of the model. While executing code instructions MetaFactory reads the model by iterating through the element hierarchy. During these iterations the code instructions and model data are combined to create the actual output code. The hierarchy of the model data file is fixed and looks as follows in XML, which file would be model.xml.

<model ...>
		<property name="property1">
	<package name="bookstore">
		<object name="book">
			<attribute name="title" type="String" notnull="false">
			<reference name="author" type="Person">
		<object name="Person">...</object>


The required namespaces to use are shown in the example below:

<?xml version="1.0" encoding="UTF-8"?>
<model xmlns="" xmlns:xsi="" xsi:schemaLocation="">



The code instructions’ logic decides whether and how to use the attributes, references, and metadata of each object (entity). Quite often you may want to define code instructions with logic that requires extra information from the entities. You can add this meta-data to the model as ‘properties’ that belong to either the package, object or attribute/reference level. With the metadata the code instructions can make decisions for how, when or in which case to generate code. Different code instructions are thus able to interpret  the model differently. For example one pattern might generate the java POJO’s (back-end) while the second pattern would generate the front-end in order to visualize and manipulate the data in the back-end. All these code instructions use the same model.

The model root element <model> can contain the following child elements which will be explained separately: