General architectural question

[dwarakaprasad]

I am trying out a blueprint that will introduce a new definition language similar to JDL called UDL (UI-UX definition language). UDL will concentrate on the presentation & the interaction part of the generator e.g. visual elements, layouts, user on-boarding workflow, etc. I have been going through generator-jhipster code base trying to understand how JDL works and my plan is to mimic something similar.

So here is what I understand (please correct me if I am wrong),

1. running jhipster jdl 21-points.jdl triggers the jhipster:jdl generator
2. The jdl files are read/downloaded and parsed to jdlObjects (containing applications, entities, deployments, etc.)
3. Generate and store *.json yeoman & jhipster config files (.yo-rc.json, .jhipster/entity*.json)
4. Based on the content (# of applications, etc.) of the jdl files, compose other jhipster generators (jhispter:app, jhipster:entities, jhipster:workspaces, an entrypoint generator)
5. The composed generator (e.g. jhipster:app) bootstraps other required generators up the chain
6. Loads the .yo-rc.json (created @ step3) into jhipsterConfig object
7. If the composed generator is of type BaseApplicationGenerator then it queues the entity related task (8 tasks) which then extracts the actual task from the generator and queues them.
   7.a. At this step (for CONFIGURING_EACH_ENTITY_QUEUE task), each .jhipster/entity*.json from step3 are read which creates the entityStorage & entityConfig and queues each entity to the generator tasks
   7.b. Also if the entity is not already present in the sharedStorage, we load them here.
8. These entity tasks within the generators (e.g. Angular, server, etc.) will generate the entity related files (which were originally part of entities, entity, entity-server, etc up until v7)

With the above understanding,

1. blueprint will have a new generator called blueprint:udl
2. blueprint:jdl will take in a new option that will capture the udl files
3. blueprint:jdl will compose the blueprint:udl with the udlFile list
4. blueprint:udl will parse and extract udlObject
5. blueprint:udl will create new .custom/*.json config files
6. blueprint:udl based on the content of the udlFiles may compose with other blueprint:generators (new module like onboarding code will be generated here)
7. Here is where I am struggling,
   A blueprint:jhipster-generators* i.e. blueprinted generators or blueprint:generator will have to read the udl config files e.g. blueprint:angular needs the udlConfig file to decide on layout etc. I am thinking to save this udlConfig (multiple possible) inside sharedData.application??? so that I don't have to pass it around to each task rather have them served as the args for the tasks.
   Question:
   I) Should I read the udlConfig*.json file in the jhipster:bootstrap-*? and load it into the sharedData.application? so that any blueprint:generator has access to it.
   II) Where is the sharedData.* being loaded from the .yo-rc.json && .jhipster/*.json in the current code
   III) Is sharedData the right place to have this config, if so where within it. If not what would you suggest.

@mshima I know you did a lot of these changes and I really appreciate if you can take a look at it.

[dwarakaprasad]

II) Where is the sharedData.* being loaded from the .yo-rc.json && .jhipster/*.json in the current code
I think I found the answer for
a. where sharedData.sharedApplication is loaded from .yo-rc.json
b. where sharedData.sharedEntities are loaded from .jhipster/*.json

So, all generators derived from BaseApplicationGenerator receives this sharedEntities and generates the entity related code.

Based on these observations, I still feel that reading the udl files in blueprint:bootstrap-application-base and loading them into sharedData.sharedApplication.udlConfig will give me global access to this data across blueprint.

[mshima]

• Loads the .yo-rc.json (created @ step3) into jhipsterConfig object

1.6. jhipsterConfig is a proxy object that is synchronized with .yo-rc.json (in-memory) content. It reloads on file change and writes on config change.
Same as blueprintConfig for blueprints.

1.7. Entities load happens on LOADING_ENTITIES

2.2 and 2.3 looks optional blueprint-cli udl file.udl makes more sense to me.

2.5 Is there a reason to don't keep configs nested inside .yo-rc.json?

Any shared data should be stored in sharedData.
You can extend base-application to add params to tasks and create others priorities.

[mshima]

Are you planing to use JDL parser as base?

[dwarakaprasad]

I have done something very similar to the JdlParser and have it working. I am not planning to extend from JdlParser.

Udl will be a separate input similar to JDL, I would like to keep JDL and UDL separate like html & css.

[dwarakaprasad]

Thank you so much @mshima for answering this and validating my understanding. Looks like this will work.