search

jhipster / generator-jhipster

JHipster is a development platform to quickly generate, develop, & deploy modern web applications & microservice architectures.
https://www.jhipster.tech
Apache License 2.0
21.54k stars 4.02k forks source link

Enhance entities/entity sub-generator context to cover more than one entity for generation #19295

Closed dwarakaprasad closed 2 years ago

dwarakaprasad commented 2 years ago
Overview of the feature request

Currently when the generation is initiated from a jdl file, the entities sub-generator (_postConstruct()method) reads the .jhipster/all-entities.json contents and composes with the the entity sub-generator (_composing() phase) at 'an entity' level (for e.g..) if there are 3 different entities, then 3 instances of entity sub-generator will be spun, each taking care of the individual entity that its attached to. The collaboration point is taken care using the needle API. This approach works out great when the collaboration code is small and simple like adding an entry to a menu, adding an entry for i18n in the webpackCustom.js fle, etc.

This approach will get complicated when the collaboration code is a complex (i.e. more than just a few lines to code that needs to be inserted into an existing file).

For example, I am trying to create a page in angular with material stepper component where each step will be an entity or I can have more than one entity in the same step (e.g. many address attached to a customer). In these situations I don't think the needle API would be the best choice.

One of the options would be to have specialized sub-generators like 'entity-client-group', 'entity-server-group', etc. to be composed from 'entities' when special keywords are used in the jdl file (e.g. combine all entities with annotation @entityGroup('group1,onlyClient') - calls only the entity-client-group with entities containing group1, @entityGroup('group2') - calls both the sub-gen with entities containing group2, etc.). This approach will help the generation of these complex situations much more easier by having access to the required entities in one place.

mshima commented 2 years ago

Not sure how the implementation would look like, looks complex and I don't understand the reason. But I think this will somewhat covered by https://github.com/jhipster/generator-jhipster/issues/19111.

dwarakaprasad commented 2 years ago

Thankyou @mshima for your quick response.

We are developing a blueprint that will generate code for a forms application. The application will have pages with questioner (like surveymonkey) and the questions/answers are built from the JDL. We use JDL's annotation to define each page (we capture a lot of metadata like order, etc here) and the entities that belong to that page.

We thought of using angular material stepper component as it naturally supports page navigation. So now we have choices like

  1. Create a component for each step and embed them into steppers step
  2. Create generate the code into the stepper itself

Approach 1 goes in-line with jhipster's one entity per 'generation context' ideology but for approach 2 that doesn't work as the file building the steps will need all the entities.

Initially we thought of going with approach 2 and that's where this enhancement came but now after re-thinking the design, it looks like approach 1 will be more cleaner with independent components (although there will be a lot of files).

We appreciate all the great work from this team...

dwarakaprasad commented 2 years ago

Based on my previous comment, closing this issue.