Closed deepu105 closed 7 months ago
My idea would be to have different sub generators:
@Entity
with repository, with mapper domain <-> entity
These sub generators can be composed with Yeoman. By using this kind of architecture, you can use separately if you want. Each sub generators can be in a separated pull requests in real projects. The pre-requisites would be the "domain" (which is not the same definition like the domain we have today)
So instead of skipping stuff, I'd prefer:
domain Product {
...
}
resource-mvc product
service product
entity product
If you want the domain object and the entity:
domain Product {
...
}
service product
entity product
Later, we can have a Kafka consumer instead of resource:
domain Product {
...
}
kafka-consumer product
service product
entity product
Hello Deepu! This solution could work but instead of skipping, I'd rather take the opposite approach (the rails one): select what should be generated instead of what should be skipped. I have to assume users know what is generated and also know what they don't want. For the users who want the "whole package", I guess the skipping could be useful.
This solution could work but instead of skipping, I'd rather take the opposite approach (the rails one)
I'm faster than you @MathieuAA :beers:
Hey both, yes that was my first thought as well, but then I started thinking about our average users who want us to provide an opinionated defaults. What you are suggesting would be good for power users and senior devs, but for someone using JHipster to learn or to quickly get something with all bells and whistles, it would be lot of friction for them to pick and choose everything.
IMO, the success of JHipster is mainly due to the fact that we cater to not-so rock star devs (average devs) and we provide an opinionated stack where everything works so IMO, JHipster by default should still be providing fully working CRUD apps and provide ability for power users to customize and pick and choose
So I don't care if it is by exclusion or inclusions as long we dont force everyone to pick and choose all the time
Yes, the goal would be to keep the behavior like today, and it should not change :
Only, the internal stuff must change:
We should keep the behaviour as is today in V7, and maybe switch only in V8 with the 'hexagonal' approach
no need to wait v8, it can be done progressively. I already have small sub generators:
By composing these 3 sub generators, it's similar to what we can have with Spring Initializr, but it's better (because of editorconfig, prettier)
By composing the init+maven, I can build a java library (already used for my current customer)
These sub generators are like module in fact, nothing new here
Currently for an entity we generate the clinet side, REST resource, service, and Repository layers and for every entity we also create CRUD + Partial update methods. This is is good for many usecases but wen you are trying to build some minimal services or microservices, there is a lot of boilerplate.
Since we do everything with templates, its quite easy for us to skip layers or parts altogether based on options in JDL
This can be quite useful to cut down on some of the boilerplate (which IMO keeps increasing with each version of JHipster 😢 I just updated a poject to v7 and it added like 1000s of lines of code, most from the partialUpdate method and stuff which is useless to me in the application)
@skipResource | @skipService | @skipRepository | @skipDto | @skipClient @skipRestMethods(PATCH, DELETE) entity Product { }
By the way this is already somewhat supported. Since dto and service are disabled by default this should work:
@Service(serviceClass) @Dto(mapstruct) @SkipClient
entity Product {
}
Yes I know about those, well I added those originally 😜, but this is to take it even further so that we can do the same for other layers as well. Probably this is in line with what Pascal has in mind as well. So lets wait for his full proposal.
On Mon, 22 Mar 2021, 6:47 pm Marcelo Shima, @.***> wrote:
Currently for an entity we generate the clinet side, REST resource, service, and Repository layers and for every entity we also create CRUD + Partial update methods. This is is good for many usecases but wen you are trying to build some minimal services or microservices, there is a lot of boilerplate.
Since we do everything with templates, its quite easy for us to skip layers or parts altogether based on options in JDL
This can be quite useful to cut down on some of the boilerplate (which IMO keeps increasing with each version of JHipster 😢 I just updated a poject to v7 and it added like 1000s of lines of code, most from the partialUpdate method and stuff which is useless to me in the application)
@skipResource | @skipService | @skipRepository | @skipDto | @skipClient
@skipRestMethods(PATCH, DELETE)
entity Product {
}
By the way this is already somewhat supported. Since dto and service are disabled by default this should work:
@Service @Dto @SkipClient
entity Product {
}
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jhipster/generator-jhipster/issues/14416#issuecomment-804265770, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIOKF33S3DD6LZLDAV4VBDTE57B5ANCNFSM4ZTOW7XQ .
So what should be the list of filters?
//Skipping layer
@SkipFaker
@SkipEntity // would result in a `List<DTO>` or `@Cacheable` in service
@SkipRepository
@SkipDTO // would result in exposing the entity to controller
@SkipService
@SkipController // No Front? No Back ITest, No Front ITest
@SkipClientService // No Front
@SkipForms
@SkipBackUnitTests
@SkipBackITests
@SkipFrontUnitTests
@SkipFrontITests
/* Question: what is the impact of each Skip compared to the other layers? */
// Skip capability
@SkipSearch
@SkipCache
//Skip entity capability
@SkipMutate
@SkipCreate
@SkipDelete
Something else? If so please copy paste and complete the list!
Me again :-),
I'm also in favour of the first suggestion of @pascalgrimaud (inclusive option) instead of using skip*: I think that this is the only solution to keep being consistent across all options.
No mention => Jhipster reasonable default. Mention => user defined behaviour. Just have to explain this in the doc :-)
Specifying like this will permit to keep being consistent between binary and unary options.
service * with serviceImpl except X,Y,Z
(impossible to achieve with a skip because of the choice that has to be made between serviceImpl and serviceClass)
`service except X,Y,Z
controller A, B, C
controller * except X, Y, Z`
This issue is stale because it has been open 30 days with no activity. Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted. We are accepting PRs :smiley:. Comment or this will be closed in 7 days
Keep open
On Fri, 4 Jun 2021, 2:25 am github-actions[bot], @.***> wrote:
This issue is stale because it has been open 30 days with no activity. Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted. We are accepting PRs 😃. Comment or this will be closed in 7 days
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jhipster/generator-jhipster/issues/14416#issuecomment-854269134, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIOKFY6WIAQL7FMWWXFKV3TRAMQZANCNFSM4ZTOW7XQ .
Yes, the goal would be to keep the behavior like today, and it should not change :
- generate the full application with these options by default
Just my thoughts as a blueprint developer: This seems ok and possibly It would be the frictionless way not requiring many changes to the blueprints.
Only, the internal stuff must change:
- splitting entity-server sub generator into smaller sub generators
Blueprint developers could (maybe optionally?) implement the sub-generators to allow skipping.
This issue is stale because it has been open 30 days with no activity. Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted. We are accepting PRs :smiley:. Comment or this will be closed in 7 days
Keep open
This issue is stale because it has been open 30 days with no activity. Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted. We are accepting PRs :smiley:. Comment or this will be closed in 7 days
Currently for an entity we generate the clinet side, REST resource, service, and Repository layers and for every entity we also create CRUD + Partial update methods. This is is good for many usecases but wen you are trying to build some minimal services or microservices, there is a lot of boilerplate.
Since we do everything with templates, its quite easy for us to skip layers or parts altogether based on options in JDL
This can be quite useful to cut down on some of the boilerplate (which IMO keeps increasing with each version of JHipster :cry: I just updated a poject to v7 and it added like 1000s of lines of code, most from the partialUpdate method and stuff which is useless to me in the application)
something like this (ping @MathieuAA )
WDYT @jhipster/developers