tutorial jhipster

tutorial - Personalizando JHipster



jhipster generator (2)

¿Es posible personalizar / extender JHipster para una organización?

Con eso, me refiero a tener una versión local que cree algunos proyectos con características que son específicas de una organización. Por ejemplo, usar un esquema de autenticación personalizado (que aún depende de la seguridad de Spring), usar estilos personalizados (colores, fuentes), agregar ciertas dependencias de Maven y así sucesivamente.

Si esto es posible, ¿se puede hacer manteniendo la posibilidad de actualizar JHipster de tal manera que una actualización de JHipster no sobrescriba estas extensiones?

Gracias.

Aquí está el enfoque en general:

  1. Primero, creamos un proyecto en blanco con toda la pila estándar de JHipster. DBMS utilizado es Postgres. Esbozamos la estructura de datos básica con la herramienta de generación de entidades jhipster, creando las relaciones más importantes, etc. También definimos los roles y permisos básicos de los usuarios dentro de las opciones estándar de JHipster. En esta fase, no prestamos mucha atención a los detalles como restricciones únicas y complejas, restricciones comerciales, administración de usuarios, manejo y presentación de errores de JPA, etc. Para empezar, solo creamos una especie de backbone. Las páginas de CRUD son todas estándar.
  2. Introdujimos alguna lógica de negocio específica de dominio. Se realizó la personalización básica del frontend: marca, estilos, algunas vistas personalizadas (todavía se usan clases de bootstrap ampliamente), etc. El marco generado por Jhipster se mantuvo en su lugar pero se extendió. Cambiamos un poco la lógica de autorización tanto en el backend como en el frontend, está basado en token con ciertas reglas de validación de token. Se introdujo un manejo de errores fácil de usar, que permite al usuario comprender qué restricciones comerciales se presentan en diversas condiciones. Comenzamos a escribir pruebas unitarias más complejas para cumplir con la lógica empresarial implementada recientemente. La mayoría de las entidades (aproximadamente el 80%) están creadas manualmente en esta etapa, porque nos acostumbramos a la estructura de datos que ofrece JHipster, y teníamos demasiada personalización en los controladores, páginas y pruebas de CRUD REST que cubrían todo eso. Los registros de cambios de liquibase se generaron con liquibase: diff y se editaron manualmente. No agregamos dichas entidades a la carpeta .jhipster.
  3. Debido a que las demandas de diseño de la interfaz son cada vez más altas y estrictas, se decidió introducir una capa frontal separada para la interacción del usuario final. Comparte parcialmente las interfaces REST con el frontend generado por jhipster, pero es absolutamente independiente en términos de la estructura del proyecto. También decidimos usar Angular para la nueva capa de frontend. De hecho, es una subcarpeta con index.html, bower.json, Gruntfile.js, etc. separados. Al mismo tiempo, continuamos mejorando la lógica de negocios, refinando la estructura de la base de datos, aumentando la cobertura del código, introduciendo nuevos roles de usuario, etc.
  4. ...

Por lo tanto, hemos personalizado ligeramente la interfaz JHipster "antigua" para fines de administración y gestión de datos. Y una "nueva" interfaz de usuario independiente con diseño personalizado para tratar con los usuarios finales. Tenga en cuenta que : es posible mantener una interfaz original, personalizarla hasta cierto límite y preservar la posibilidad de generar entidades, y funcionó bien en nuestro proyecto en la medida en que se justificó.

Algunas notas:

  • Las versiones de los componentes en pom.xml se actualizaron constantemente a mano;
  • Las dependencias de Maven se agregaron manualmente a pom.xml;
  • Las dependencias de JS se agregaron manualmente a index.html / bower.json / app.js;
  • Si tiene scripts de frontend complejos, tratar con la verificación de JS para el perfil de producción puede ser complicado;
  • Otra cosa difícil es mantener los scripts de liquibase trabajando para DBMS utilizados por spring-boot y H2 que se usan para pruebas;
  • Probablemente enfrentará algunos problemas con el ajuste de la configuración dependiendo de la lógica de dominio específica para su proyecto.

Espero que ayude.

Otro enfoque que se ha introducido en la versión 2.26.0 (a mediados de diciembre de 2015) es crear sus propios módulos, consulte la documentation .