Options generation annotations on entities

[Tcharl]

Overview of the feature request

The goal would be to add some jdl annotations and cli options on entities.

The goal would be to split annotations into two categories: layer ones vs C-R-U-D ones.

-- Frontend --

• @Form would generate frontend forms
• @FrontClient would generate client-side consumer no matter the consumption strategy

-- Controllers --

• @RestController would use api
• @SSEController would use streaming (listeners and senders)
• @StreamConsumer(<topics>) would Consume message via streams (data coming from other microservice)

-- Services --

• @RestClient(<toApplication>/<toEntity>) would call the target service api instead of repository in the service implementation.
• @StreamProducer(<topics>) would hook service.save() and send messages in the topics instead of using repositories
• @RepositoryConsumerwould use usual spring data providers

-- Data consumption --

• @Repository would generate only entity and spring data repository for an entity.

-- C-R-U-D --

Same logic to be applied to methods (create:update/patch/get/delete), decorelated to layers.

--- summing up As such, 'reasonable default' as per Inclusive property rfc would be:

@Form
@FrontClient
@RestController
@RepositoryConsumer
@Repository
entity <name>{ ... }

and for crud:

// Won't generate the 'delete button', neither the methods
@CREATE
@GET
@GETALL
@UPDATE
entity <name>{ ... }

And to let user be more precise by combining both (overriding class-level choices):

@Form(methods=[@GET,@UPDATE]) // this choice won't generate the 'creation' form
@FrontClient
@RestController
@RepositoryConsumer
@Repository
@CREATE
@GET
@UPDATE
entity <name>{ ... }

Motivation for or Use Case

The goal would be to provide much more control on entities generation

The ultimate goal being to provide a versatile solution for complex applications with few effort from the end user (plumbery jhipster-managed), i.e.

application clientCartPortal {
  entities: PurchaseRequest
  type: gateway
}
application supplySink {
  entities: Supply,Order
  type: microservice
}
application supplyOperatorPortal {
  entities: Shipping,OrderStatus
  type: gateway
}

@Form
@FrontClient
@RestController
@StreamProducer(topics=[orders])
@CREATE
@UPDATE
@GET
entity PurchaseRequest extends Supply {} // can just replicate the fields while extensions not supported

@StreamConsumer(topics=[orders])
@RepositoryConsumer
@StreamProducer(topics=[shipped]) // user will just have to filter element with status 'shipped' to the stream
@Repository
entity Supply {
  quantity int
  itemId UUID // or relations to stock.item
  unitprice float
}

entity OrderStatus {
  status: enum [Waiting,Processing,Shipped]
}

oneToMany {
Supply{status} to OrderStatus{supplies}
}

@Form
@FrontClient
@StreamConsumer(topics=[supplies])
@SSEController
@GETALL
entity Shipping extends Supply {} // shipping portal will receive updates ;-)

I want to contribute to this feature, however, seems huge so need some workforce help + bounties please (to motivate other contributors)! @qmonmert @mshima @mraible @MathieuAA wdyt ?

• [ x ] Checking this box is mandatory (this is just to show you read everything)

[MathieuAA]

Hello everyone, while I don't doubt it's doable right now, there may first have to be a design phase so as to make the necessary adjustments to the parsing system, then another change in the generator. The JDL parsing system identifies what's relevant, map and store it in some way, then creates objects (different from JHipster object shapes) based on what has been previously read. Why it is relevant: this intermediary step is necessary so as not to be tightly bound to the generator. And yes, this requires a last mapping to get JHipster shapes, this is by design and should not be changed IMO. What happens without it: one makes changes to the generator system, then makes a similar change to the parsing system (here be binding). Now say one wants to change the generator in some fashion, and forgets to change the parsing system accordingly. The next time someone wants to change both, there will be a difference between the two and a confusion: what version is right? (That's why tests are important.)

To sum up, to bind every annotation to a specific generation, my opinion is that one has to: make a change to the parsing system to acknowledge said change, wire it to the generator with an explicit mapping (we leave the parsing system to enter the generator system, this gate matters), and then read the output of this mapping to generate what's wanted.