Personnalisation De JHipster

Voici l'approche en général:

1. tout d'abord, nous avons créé un projet vierge avec tous les JHipster standard pile. Le SGBD utilisé est Postgre. Nous avons décrit la structure de base des données avec jhipster entity generation tool, la création de la plus importante relations etc. Nous avons également défini la base des rôles d'utilisateur et les autorisations dans les options standard de JHipster. À cette étape, nous n'avons pas à payer très beaucoup d'attention aux détails tels que les contraintes Complexes uniques, restrictions commerciales, utilisateur gestion, JPA traitement des erreurs et présentation etc. Juste créé une sorte de colonne vertébrale pour commencer. Les pages CRUDS sont toutes standart.
2. nous avons introduit une certaine logique commerciale propre au domaine. La personnalisation de base de frontend a été effectuée: branding, styles, quelques vues personnalisées (encore utilisées bootstrap classes intensivement) etc. Le cadre produit par Jhipster a été maintenu en place, mais prolongé. Nous avons un peu changé la logique d'autorisation sur les deux supports et frontend, c'est basé sur un token avec un certain token validation règle. Une gestion des erreurs conviviale a été introduite, permettant à l'utilisateur de comprendre quelles restrictions commerciales apparaissent dans diverses conditions. Nous avons commencé à rédiger des tests unitaires plus complexes pour répondre à la logique opérationnelle mise en œuvre récemment. Les Entities sont principalement (~80%) conçues manuellement à ce stade, parce que nous nous sommes habitués à la structure de données offerte par JHipster, et nous avions trop de personnalisation dans les contrôleurs CRUD REST, les pages et les tests couvrant tout cela. Des changelogs de Liquibase ont été générés avec liquibase: diff et édité manuellement. Nous n'ajoutons pas de telles entités .dossier jhipster.
3. en raison des exigences croissantes en matière de conception d'interfaces, il a été décidé d'introduire une couche frontale distincte pour l'interaction avec l'utilisateur final. Il partage partiellement les interfaces REST avec JHipster-generated frontend, mais est absolument indépendant en termes de structure de projet. Nous avons décidé d'utiliser L'angle pour la nouvelle couche de frontende aussi bien. En fait, c'est un sous-dossier avec index séparé.HTML, Bower.json, Gruntfile.JS etc. Dans le même temps, nous avons continué à améliorer la logique commerciale, à affiner la structure des bases de données, à augmenter la couverture du code, à introduire de nouveaux rôles d'utilisateur, etc.
4. ...

ainsi, nous avons légèrement personnalisé" Vieux " JHipster frontend pour l'administration et la gestion des données. Et une "nouvelle" interface indépendante avec un design personnalisé pour traiter avec les utilisateurs finaux. remarque: il est possible de conserver une interface originale, de la personnaliser à une certaine limite et préserver la possibilité de générer des entités, et il a bien fonctionné dans notre projet aussi loin qu'il était justifié.

Quelques remarques:

• versions de Composants dans le pom.xml ont été constamment mis à jour à la main;
• les dépendances Maven ont été ajoutées manuellement à pom.xml;
• les dépendances JS ont été ajoutées manuellement à l'index.html / bower.JSON / app.js;
• si vous avez des scripts frontend complexes, traiter de la simplification pour le profil de production peut être délicat;
• une autre chose difficile est de garder les scripts liquibase fonctionnant à la fois pour les SGBD utilisés par spring-boot et H2 qui est utilisé pour les tests;
• vous allez probablement rencontrer des problèmes avec le réglage de la configuration en fonction de la logique du domaine spécifique à votre projet.

j'espère que cela aide.