These files can import data type definitions from delphi.
They are run by the frontend,
which analyzes the files specified within and generates a
corresponding User Type Definition
You have to be careful to edit a file with the ending .g.yml,
This is the convention for automatic generated types, which will be overwritten by every converter run.
The format itself is a simple but sufficient DSL, as the example from the Demo will show you:
Important: you can specifiy mulitple in/import/using pairs within a from ... end block,
This will import several types at once (useful for dependent files)
This keyword loads a directory for input processing
Specifies a delphi source file from which to import data types. (wildcards not supported yet)
This can either be a concrete type name or a wildcard *,
Which imports all files, which is the preferred option.
This is an optional keyword and is required if you don't want to import the file into the output folder,
But rather you want to use one of your packages this file is contained in.
This helps avoiding import conflicts within your Delphi project, as one unit can only be imported once in certain cases.
The input to the program is mostly defined in a human-editable markup format, based on the YAML specification.
Listed is a certain set of rules which have to be followed:
Every YAML document starts with a version and a document separator.
The fully qualified name of the document is the root of all nodes, i.e. it serves as a common namespace.
When using a language which support namespaces, all elements will be defined in that namespace.
Following the Java package convention, the file name should match the namespace, this keeps things in order.
Import of other YAML documents, this is used by the User Type Definition engine to reference other types. It also imports the namespace as above
Tthe order of the keys in the hashmap does matter (i.e.)
In a future version, this requirement might be dropped, when there is a dependency resolution mechanism to resolve the order of statements.
Nonetheless, the implementation used does keep the input order intact, so it won't create any problems.
For defining remote callable modules in your programs, you need
an interface specification
For now, these need to be manually edited, but do not fear, it
follows a Common file specification based on YAML, so
Here you can define methods and their parameters, using .NET
primitive types, arrays and the User Type Definition.
To get a broader overview, here is a listing of the Demo
Project source file: