This DiF concept is more alive in this topic than any other.
Annotations are what makes this model simple and feasible.
What we set out to do in DiF is a framework where most things are taken for granted since they are commonly needed witch falls in the convention category.
Many things are frequently necessary, and so, can be requested witch falls in the configuration category.
And as fewer things as possible are only possible through code, the programming category.
How can we do this?
We place annotations in our code.
Through bytecode generation DiF reads these annotations and inserts code in our classes. Much code will be added. This code will react to your annotation parameters, to your own code and to available plug-ins in your DiF setup.
All this "artificial intelligence" will make the above concept possible.
It is therefor mandatory that a DiF developer knows well what annotations he can use.
DiF annotations are basically a simplified API that the developers use which shields him from the hard-code inner API, and, as stated, that saves him the trouble to know many DiF internals and create loads of lines of code.
For a full list of all annotations and how to use them, we redirect you to the dif-core module annotations reference page.
DiF is extensible almost in every way. This is no exception.
You can create your own annotations and instruct DiF on how to validate them, and how to generate code when they are used, if needed.
For this you have to create java code of course, and... yes, you guessed it... annotate that code. Same principle.
A full list of the meta-annotations is available, on yet another dif-core module page.