[JAVA] Thymeleaf a fait du HTML une partie commune pour unifier la conception et améliorer l'efficacité du développement.

Dans un environnement Spring Boot + Thymeleaf, plusieurs personnes peuvent développer le front-end, C'est un mémo que lorsque la même structure et la même conception apparaissent souvent, il y avait un tel problème et il a été résolu. (Même si quelqu'un prend le relais, cela peut être une fourmi pour en faire une partie commune)

environnement

Spring Boot: 1.3.2 RELEASE Thymeleaf: 2.14 RELEASE

Qu'est-ce que Thymeleaf

C'est l'un des moteurs de modèles et il est recommandé pour une utilisation dans un environnement Java. Ce que j'aime, c'est que vous pouvez intégrer la propre syntaxe de Thymeleaf dans HTML. Écrivez d'abord du HTML natif, déterminez grossièrement la structure et la conception, et ne cassez pas trop le code Vous pouvez le compléter. (Je n'ai jamais utilisé aucun autre moteur de template ... c'est peut-être ce que le monde veut dire) On dit que vous pouvez faire diverses choses (bien que ce soit approximatif) en le combinant avec Spring Boot. Site officiel: http://www.thymeleaf.org/

Des défis sur le terrain où j'étais

En fait, c'était il y a un peu moins de deux ans, et je suis récemment revenu au front-end et je m'en suis souvenu, alors je l'ai écrit. A cette époque, en plein développement, j'avais les problèmes suivants.

• Plusieurs personnes ont implémenté des modèles d'écran, et il y avait des variations dans la structure et la conception mises en œuvre par chacun. (Il y avait une norme de codage, mais malheureusement tout le monde n'y adhérait pas, il n'était donc pas réaliste d'améliorer la norme (je me demande encore si ce jugement était correct. Je l'ai amélioré plus tard. Mais ça aurait dû être le premier ...))
• À mesure que le nombre de tâches de développement côté serveur augmentait, un petit nombre de personnes (efficacité) ont été nécessaires pour implémenter des modèles d'écran. (En fin de compte, j'ai dû créer moi-même des dizaines de modèles d'écran par semaine)

Parties communes fabriquées avec Thymeleaf

De la conclusion, je vais faire comme ça (j'omettrai la syntaxe de Thymeleaf).

Votre interlocuteur

<!-- form.texte en html-Appelez une partie appelée formulaire.
En tant qu'argument, templateId, label,Passe requis.
templateId"accountName"Passez la chaîne de caractères.
l'étiquette est msg dans la ressource de message.account.Passez la chaîne définie dans nom.
Passez faux pour obligatoire-->
<div th:replace="form :: text-form(
    templateId = 'accountName',
    label      = #{msg.account.name},
    required   = false)">
</div>

Parties communes

<!-- text-C'est une partie nommée forme.
En tant qu'argument, templateId, label,Recevoir requis.-->
<div th:fragment="text-form(templateId, label, required)">
    <label th:for="${templateId}" th:text="${label}"></label>
    <div>
        <input type="text" th:id="${templateId}" th:name="${templateId}" th:field="*{__${templateId}__}"
               th:required="${required}? required"/>
    </div>
</div>

En fait, il existe une application de classe CSS et un appel Javascript, ce qui complique les choses, mais si vous définissez des parties communes, Vous pouvez créer efficacement une structure avec une conception unifiée simplement en transmettant les paramètres nécessaires aux pièces nécessaires et en les appelant.

Problèmes après la fabrication de pièces communes

Nous avons pu unifier la conception, développer efficacement des modèles d'écran et les publier comme prévu. Cependant, à mesure que le développement progressait, les problèmes suivants se sont posés.

• Les pièces communes étant fabriquées en unités de différences de conception, un grand nombre de pièces communes ont été créées et le coût de recherche de pièces communes appropriées a augmenté. → Par exemple, si vous écrivez la syntaxe du commutateur dans les parties communes de la plage où les arguments ne changent pas, vous pouvez réduire le nombre de parties et l'améliorer. → Il peut s'agir essentiellement d'un problème de conception.
• Nous n'avons pas pris suffisamment de temps pour concevoir les unités à utiliser comme pièces communes, et il existe de nombreuses pièces communes fabriquées dans des unités qui ne sont pas optimales. → Dans l'exemple de code ci-dessus, il s'agit d'une unité de formulaire, mais est-ce optimal? Il devrait y avoir une vérification pour chaque produit. → C'est une bonne idée d'utiliser pleinement la fonction layout-dialect (http://www.ultraq.net.nz/thymeleaf/layout).

Ce que je pense personnellement

• Il peut y avoir eu un moyen de génération automatique en premier lieu → Je n'avais aucune idée à ce moment-là, mais ... À l'heure actuelle, l'essentiel est de le réparer, mais cela aurait dû être très utile à ce moment-là.
• Il peut y avoir un moyen plus efficace de créer des parties communes en mettant à jour vers Thymeleaf 3.x. → Il y avait de nouvelles fonctions qui pouvaient être utilisées pour créer des parties communes. Il est rétrocompatible, vous ne devriez donc pas avoir trop peur