I am developing a jhipster blueprint (base generator 7.8.1) that will have a completely different angular UI with Jhipsters spring-boot backend with customization. I have got the UI part working (using mock backend) and now, I am trying to customize the server sub-generator.
My needs are to be able to modify the base generator templates and also add new templates/files.
Very first use case I am trying to solve is to modify the SecurityConfiguration_reactive.java.ejs (basically add more routes). I have tried the following option in the blueprint's generators/server sub-generator and it worked,
Create an index.js file, delegate all the priorities to the base generator except the writing priority. The writing phase will basically call the base generators writeFilesToDisk(serverFiles) method where the serverFiles is from the blueprint.
Copy the files.js from the base generator to the blueprint - this is the serverFiles from the previous call
Copy the template from the base generator (follow the same folder structure) and make the customization
I also came across this post that had a better approach but its a little old. So, is there a better way to achieve this?
Any help is greatly appreciated...
Related
I am trying to override the a template Entity.java.ejs in my custom blueprint to add some extra functionality. Unfortunately JHipster uses its default one if generate an entity. I don’t want to overwrite the whole writing. Is there a possibility to override only certain ones and use JHipster default templates for the rest?
Helo friend,
in this period I see an application jhipster with a partial custom .ejs defining a default for others components.
The problem is that the overriding is very huge, and cabled only for a specific version 6.9.1 of jhipster.
If this is a good idea to custom a particolar application with a particolar version and with a specific cabling code ok, but is not good if you want a generic custom generator jhipster context, where you can "inject" only custom files, giving overriding of all scope original generator.
I try to search some answers searching on web, and your question is anyway a good clue to define a better solution that I see now.
The problem that I see is that jhipster environment dont have a "handling" approach about .ejs templates, when is very strong and straighweird when you use .jdl file .
An easly customization of templates of any jhipster application created with command "jhipster", ad example.
And searching I see this link https://github.com/jhipster/generator-jhipster/issues/1749
an issue of original jhipster generator where someone consider a good idea to use "subgenerator" using yeoman to modulerize this templates and with all benefits.
This is a another clue to understand somethings.
good luck and thanks
I work into a existing nodeJS project and I would like to use swagger codegen to automate the documentation.
Currently I write the swagger doc after to have code and there is always a time lag between dev and production....
I find two solutions. The first generate the node js projet and after you code inside, but my project have one year and lot of code...
The second solution is to write a syntax in my code and automate the documentation after with command line but this solution don't use yaml and my actual doc is to write is Yaml...
Thanks :)
If your existing node.js project uses Express as its web framework, you could consider using swagger-spec-express which would enable you to simply annotate your existing express api with swagger info.
I have an application developed with Node.js/expressjs. It's working fine. Now I need to generate API document using Swagger. There is a module swagger-node. Do I need to re-write the whole app using this module or is there any other solution to use this module and what is the use of swagger-ui if using swagger-node.
Not from what I can tell. You should be able to generate your swagger project as described, and then just make sure that the information in the yaml file points to the actual controllers and methods that your code uses.
You can create a standalone yaml file that is compliant with Swagger/OpenAPI which can therefore be rendered into Swagger documentation. The Swagger-UI is useful for creating this yaml file. Swagger also offers various tools for testing APIs and generating code -- to use these effectively you will need a method for integrating the controller/model definitions in your yaml file into your existing codebase.
To achieve this integration I typically expose my existing codebase as an api of controller functions -- then import it as a module into the code generated by my documented API. This allows me to trust my API documentation without the burden of porting my whole codebase into Swagger's required directory structure. I believe this is the best currently available approach but is not always worthwhile.
i'm newbie in JHipster and i'm trying to figure this, when i create a new entity JHipster generates several files, angular, html and java classes, now if i want a common code for all this generated code i must edit each time that i use the yeoman generator? what i want is:
Custom Index template, and pages, is secure to edit them?.
Customize the entity tables, entity forms using angular, maybe extending yeoman generators
Customize generate java classes, maybe i think using AOP
So i need to edit each time for each generated code? and is a good practice this or what i want? for clarify more i want to use a Custom Bootstrap/angular Dashboard template like Minovate, i see how to customize bootstrap in the documentation but not about what i'm asking for, Thanks.
JHipster is just a code generator, once generated the code is yours.
For angular screens I would say do as much as you can in CSS/SASS.
But it's very likely that you will need to build some screen mixing several entities and change the structure of entity screens.
So you should rather consider them as a starting point and do your own stuff in another folder so that it does not get overwritten by next re-generations.
This way you can still update your entity definitions in .jhipster folder and re-run yo jhispter:entity <entity name> on the entities you modified.
Customising java Entities is usually much simpler and you can easiliy achieve this by merging generated code with git and defining your service classes.
AOP seems overkill here.
Extending a yeoman generator is a lot of work.
I suggest to use some VSC (git, subversion or whatever you like) have a branch dedicated to plain jhipster generated code and another one where you make customization.
Eventually regenerate on jhipster branch and merge back on yours.
You should at least reduce manual intervention.
This is more for some fun and playing around with, but hopefully should produce something useful.
I would like to extend sails.js framework so that when I generate a new app using 'sails new project-name' it will already have a lot of previous configurations or modules added. For example, with every project I would probably intend to use SASS. If you have had to setup SASS with sails before you will know it has a few bits of configuration to do first. It would be advantageous to not have to repeat this with each new project.
In short some things I would like to achieve upon creating each new project:
Get SASS configured
Generate multiple SASS partial files, such as _buttons.scss, _forms.scss
Include SASS mixings within certain SASS files
Include configuration and set up to use multiple databases like mongoDB and MariaDB (Much more complex I imagine)
Thanks
At Balderdash we do this all the time to quickly spin up certain "types" of application.
You can fork https://github.com/balderdashy/sails-generate-new and customize it to call additional generators that you can create using ejs templates.
I created a module called sails-generate-entities which you can see in use here: https://github.com/tjwebb/sails-permissions/blob/master/index.js. For this sails extension, you'd call sails generate permissions-api and all those files would be added to the project. Your fork of sails-generate-new could include a call to a custom generator such as this.