Generate thymeleaf forms from JDL based on the "no client" selection on mhipster

[kevintanhongann]

Overview of the feature request

This feature request is about generating Thymeleaf forms based on the JDL script with entities and relationships.

Motivation for or Use Case

The reason behind the feature request is when one generates a mHipster project and one generates a no-client skeleton project, one has the option to code a monolithic app based on Micronaut + Thymeleaf flavor, which is pretty decent and there's no reliance on any Javascript frontend frameworks except for jQuery or Tailwind(depending on whether you're coding it or buying html templates from a site). And based on my experience, I deliver faster by buying existing html templates from Themeforest and start coding and delivering right away(I like delivering fast). The only drawback here is the mHipster generator doesn't have any generators for Thymeleaf forms. Since I also have the experience of using Grails before, I know for a fact that Grails uses reflections in its internals to do code generation, and mHipster really changes things since you can generate Thymeleaf forms based on the entity JSONs within the .jhipster folder.

Related issues or PR

none

[mraible]

If you'd like to create a blueprint for this, it should be possible and widely appreciated. However, making it work is one thing, maintaining it for years to come is another. It's a cool idea that many folks would like, but it's possible the maintenance burden would make you question the choices you've made in life. 😉

[atomfrede]

What Matt said. In particular doing it for micronaut blueprint. I would suggest to start for spring. Maybe even keep the usual json API and create the new controllers besides the generated controller instead of trying to modify the generated ones.

…

On Mon 8. Aug 2022 at 05:55, Matt Raible ***@***.***> wrote: If you'd like to create a blueprint for this, it should be possible and widely appreciated. However, making it work is one thing, maintaining it for years to some is another. It's a cool idea that many folks would like, but it's possible the maintenance burden would make you question the choices you've made in life. 😉 — Reply to this email directly, view it on GitHub <#266 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABRVCPMPCBB3IVEFZXKW7DVYCAK3ANCNFSM553T4J5A> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[kevintanhongann]

@atomfrede now that you've mentioned it, it makes more sense to do it in the original Spring Boot flavor first before doing it for Micronaut. I want to see the commonalities between the two flavors and assess whether it's beneficial to create a blueprint for this. Thanks for the input on that.

[atomfrede]

There is a blueprint for spring version of the Generator. As native images are part of micronaut I would not create an additional blueprint. Combining multiple blueprints customizing same generator parts is also quite complicated.

…

On Tue 9. Aug 2022 at 06:59, Kevin H.A Tan ***@***.***> wrote: @atomfrede <https://github.com/atomfrede> now that you've mentioned it, it makes more sense to do it in the original Spring Boot flavor first before doing it for Micronaut. I want to see the commonalities between the two flavors and assess whether it's beneficial to create a blueprint for this. Thanks for the input on that. — Reply to this email directly, view it on GitHub <#266 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABRVCLJJ5EPOGN64HGA5WDVYHQUVANCNFSM553T4J5A> . You are receiving this because you were mentioned.Message ID: ***@***.***>