-
Notifications
You must be signed in to change notification settings - Fork 17
Domain Model Annotation
See latest version in maven central.
Maven
<!-- The dependency for the annotations, field ID, constraints -->
<dependency>
<groupId>io.doov</groupId>
<artifactId>doov-core</artifactId>
<version>LATEST</version>
</dependency>
Gradle
dependencies {
compile group: 'io.doov', name: 'doov-core', version:'2.+'
}
This documentation is based on the sample project in
dOOv. You can replace
the package name io.doov.sample
by your package name as com.example.myapp
and classes name Sample
with MyApp
.
The idea behind dOOv is that you "key" (annotate with an ID) each field you will want to query later. Those keys are used as a base for the code generator that will produce the DSL.
You first need to create a path annotation, a field ID, a readable and a path constraint:
- path annotation make possible the annotation of a field in your model, it contains the field ID, the readable of the field, and the path constraint (optionnal).
- field ID is the ID of the field, it needs to be unique in the model class (not in the whole model).
- readable (optionnal) is the human-readable form of the field, is it used in code generation and in the generated abstract syntax tree (if not provided the ID is used).
- path constraint (optionnal) limits the possible paths to a field from the root of your model, this helps the code generator understand a complex model (if not provided the code generator might stop in ambiguous cases).
package io.doov.sample.field;
@Path
@Retention(RetentionPolicy.RUNTIME)
public @interface SamplePath {
SampleFieldId field();
SampleConstraint constraint() default SampleConstraint.NONE;
String readable() default "";
}
package io.doov.sample.field;
public enum SampleFieldId implements FieldId { EMAIL }
package io.doov.sample.field;
public enum SampleConstraint implements PathConstraint { NONE }
You can then annotate your model with the annotation SamplePath
and the field
ID EMAIL
you created.
You need a root model class that will be used as a starting point for the code generator. It is a common pattern to have multiple root class, with multiple code generation, that will generate multiple DSLs.
package io.doov.sample.model;
public class SampleModel {
private Acccount account;
public Acccount getAcccount() {
return account;
}
public void setAcccount(Acccount account) {
this.account = account;
}
}
package io.doov.sample.model;
public class Account {
@SamplePath(field = SampleFieldId.EMAIL, readable = "account email")
private String email;
public String getEmail() {
return email;
}
public void setEmail(String email) {
this.email = email;
}
}
Operator are already i18n in dOOv. You can also translate your domain model.
Instead of using a string in the readable
attribute in your path annotation,
you can use a key string that will be used to load the corresponding key in the
resource bundle.
package io.doov.sample.model;
public class Account {
@SamplePath(field = SampleFieldId.EMAIL, readable = "account.email")
private String email;
}
The resource bundle that is automaticaly loaded needs to be located in
io.doov.sample.field.i18n
, and named SampleModelResourceBundle
(because you
model root is SampleModel
). You can also register more bundle by calling
io.doov.core.dsl.meta.i18n.ResourceBundleProvider#register
.
account.email=Courriel du compte
See DSL Code Generation.