JHipster Domain Language (JDL) - Options Permalink to " JHipster Domain Language (JDL) - Options"

Summary Permalink to "Summary"

In JHipster, you can specify options for your entities such as pagination or DTO. You can do the same with the JDL, either with annotations on the entity, or with the following syntax:

entity A {
  name String required
}
entity B
entity C

dto A, B with mapstruct

paginate A with infinite-scroll
paginate B with pagination
paginate C with pager  // pager is only available in AngularJS

service A with serviceClass
service C with serviceImpl

The complete list of available options is here.

1. How to
2. Syntax
3. The use XYZ options
4. Examples
   1. Basic unary example
   2. Basic binary example
   3. all, * example
   4. all, * example with exclusions (unary)
   5. all, * example with exclusions (binary)
   6. Option with custom values
   7. Mixed example
5. About services
6. Microservice-related options
7. Custom annotations
8. Available options
9. See also

How to Permalink to "How to"

There are two kinds of options:

• unary (without option value)
• binary (with value)

There are three ways to apply options to entities:

• using the option name (dto, readOnly, etc.), see examples
• using annotations
• use the use XYZ form

Mixing them is not recommended as it reduces readability.

Syntax Permalink to "Syntax"

For the regular form:

<option name> <option entity list>

or

<option name> <option entity list> with <option value>

or

<option name> <option entity list> with <option value> except <option excluded entity list>

or 

<option name> <option entity list> except <option excluded entity list>

• For unary options:
  • the option name and the list is needed
  • the excluded entities are optional with the except keyword (see below for more details)
• For binary options:
  • the entity list precedes the with keyword and the option value
  • again, the excluded entities are in the end with the except keyword

For annotations:

@<option name>
entity <entity name>

or

@<option name>(<option value>)

• Similar to Java, annotations may take values in parentheses
  • depending on the option, values may or may not be optional

The use XYZ options Permalink to "The use XYZ options"

With the use-option form, you can specify some options on your entities. It was created during JHipster Code 2020, and the reasons behind its creation are to:

• Solve the option-disabling issue (there are more than one way to say ‘no’ in JHipster: no, false, none)
• Propose a way to group options by entities

entity A
entity B
entity C

use serviceClass for * except C
use mapstruct, serviceImpl, infinite-scroll for A, B
use pagination for C

Examples Permalink to "Examples"

Each example will have three forms:

• the regular one
• the annotation-based one
• the use form (when applicable)

Basic unary example Permalink to "Basic unary example"

Regular:

entity A

readOnly A

Annotation-based:

@readOnly
entity A

Basic binary example Permalink to "Basic binary example"

Regular:

entity A

dto A with mapstruct

Annotation-based:

@dto(mapstruct)
entity A

With the use keyword:

entity A

use mapstruct, serviceImpl, pagination for A

all, * example Permalink to "all, * example"

all and * are aliases.

Regular:

entity A
entity B

dto all with mapstruct

Annotation-based:

@dto(mapstruct)
entity A

@dto(mapstruct)
entity B

With the use keyword:

entity A
entity B

use mapstruct, serviceImpl, pagination for *

all, * example with exclusions (unary) Permalink to "all, * example with exclusions (unary)"

Regular:

entity A
entity B

skipClient * except A

Annotation-based:

entity A

@skipClient
entity B

With the use keyword:

entity A
entity B

use mapstruct, serviceImpl, pagination for * except A

all, * example with exclusions (binary) Permalink to "all, * example with exclusions (binary)"

Regular:

entity A
entity B

dto all with mapstruct except A

Annotation-based:

entity A

@dto(mapstruct)
entity B

With the use keyword:

entity A
entity B

use mapstruct, serviceImpl, pagination for all except A

Option with custom values Permalink to "Option with custom values"

entity A
entity B

microservice all with mySuperMS

Mixed example Permalink to "Mixed example"

Regular:

entity A
entity B
entity C

readOnly B, C
dto * with mapstruct except C
service * with serviceClass except C
search A with elasticsearch

Annotation-based:

@dto(mapstruct)
@search(elastisearch)
@service(serviceClass)
entity A

@readOnly
@dto(mapstruct)
@service(serviceClass)
entity B

@readOnly
entity C

About services Permalink to "About services"

No services specified will create a resource class which will call the repository interface directly. This is the default and simplest option, see A.

service with serviceClass (see B) will make the resource call the service class which will call the repository interface. service with serviceImpl (see C) will make a service interface which will be used by the resource class.

The interface is implemented by a concrete class which will call the repository interface.

Using no service unless sure is the simplest option and good for CRUD. Use service with a Class if you will have a lot of business logic which will use multiple repositories making it ideal for a service class. JHipsters are not fan of unnecessary Interfaces but if you like them go for service with impl.

entity A
entity B
entity C

// no service for A
service B with serviceClass
service C with serviceImpl

Microservice-related options Permalink to "Microservice-related options"

As of JHipster v3, microservices can be created. You can specify some options to generate your entities in the JDL: the microservice’s name and the search engine.

Here is how you can specify your microservice’s name (the JHipster app’s name):

entity A
entity B
entity C
microservice * with mysuperjhipsterapp except C
microservice C with myotherjhipsterapp
search * with elasticsearch except C

The first option is used to tell JHipster that you want your microservice to deal with your entities, whereas the second specifies how and if you want your entities searched.

Custom annotations Permalink to "Custom annotations"

Custom annotations are possible in the JDL, for instance:

@customAnnotation(customValue)
entity A

The main use case for this is for blueprints: sometimes, you need have custom options for entities, or even fields. For regular options (dto, pagination, etc.), these options will be generated in the JSON like in the CLI. However, for custom options, they will be generated under and options key in the dumped JSON.

Available options Permalink to "Available options"

Not what you’re looking for? Check the application options.

Entity options Permalink to "Entity options"

Here are the entity options supported in the JDL:

Field options Permalink to "Field options"

Here are the field options supported in the JDL:

See also Permalink to "See also"

The application options are available here