自定义JHipster

Question

是否可以为组织定制/扩展JHipster？

那么,我的意思是有一个本地版本创建一些具有特定于组织的功能的项目？例如,使用自定义身份验证方案(仍然依赖于Spring安全性),使用自定义样式(颜色,字体),添加某些Maven依赖项等.

如果这是可能的,可以在保留以更新JHipster不会覆盖这些扩展的方式更新JHipster的可能性的同时完成吗？

谢谢.

Answer 1

这是一般的方法:

1. 首先,我们创建了一个包含所有标准JHipster堆栈的空白项目.使用的DBMS是Postgres.我们用jhipster实体生成工具概述了基本数据结构,创建了最重要的关系等.我们还在标准JHipster选项中定义了基本的用户角色和权限.在这个阶段,我们并没有非常关注复杂的独特约束,业务限制,用户管理,JPA错误处理和演示等细节.刚开始创建一种主干.CRUD页面都很标准.
2. 我们介绍了一些特定于域的业务逻辑.执行了基本的前端自定义:品牌,样式,一些自定义视图(仍广泛使用引导类)等.Jhipster生成的框架保持到位但扩展.我们在后端和前端都稍微改变了授权逻辑,它是基于令牌的,具有某些令牌验证规则.引入了用户友好的错误处理,允许用户了解在各种条件下出现的业务限制.我们开始编写更复杂的单元测试来满足最近实现的业务逻辑.在这个阶段,实体大多是(~80%)手工制作,因为我们已经习惯了JHipster提供的数据结构,而且我们在CRUD REST控制器,页面和测试中有太多的自定义,涵盖了所有这些.使用liquibase:diff生成Liquibase更改日志并手动编辑.我们不会将此类实体添加到.jhipster文件夹中.
3. 由于对界面设计的要求越来越高且越来越严格,因此决定为最终用户交互引入单独的前端层.它部分地与jhipster生成的前端共享REST接口,但在项目结构方面完全独立.我们决定也将Angular用于新的前端层.实际上,它是一个带有单独的index.html,bower.json,Gruntfile.js等的子文件夹.同时我们继续改进业务逻辑,改进数据库结构,增加代码覆盖率,引入新的用户角色等.
4. ...

因此,我们为管理和数据管理目的提供了略微定制的"旧"JHipster前端.还有一个独立的"新"前端,采用定制设计来处理最终用户.请注意:可以保留原始界面,将其自定义到某个限制并保留生成实体的可能性,并且只要合理,它在我们的项目中运行良好.

一些说明:

• pom.xml中的组件版本不断更新;
• Maven依赖项被手动添加到pom.xml;
• JS依赖项被手动添加到index.html/bower.json/app.js;
• 如果您有复杂的前端脚本,那么处理生产概要的JS uglification可能会很棘手;
• 另一个困难的事情是保持liquibase脚本适用于spring-boot使用的DBMS和用于测试的H2;
• 根据特定于项目的域逻辑,您可能会面临配置调整方面的一些问题.

我希望它有所帮助.

Answer 2

2.26.0版(2015年12月中旬)中引入的另一种方法是构建自己的模块,请参阅文档.