Grails: Modèles vs TagLibs. [fermé]

Question

Dans Grails, il existe deux mécanismes de modularité dans les couches de vue:. Modèle et TagLib

Alors que je suis en train d'écrire ma propre application Grails, je suis souvent face à la même question quand je dois écrire un composant d'interface utilisateur: Ai-je besoin d'utiliser un modèle ou un TagLib

Après une recherche sur le web, je ne trouve pas beaucoup de les meilleures pratiques ou règles générales concernant cette décision de conception, donc pouvez-vous me aider et me dire:

1. Quelle est la principale différence entre les deux mécanismes?
2. Dans quels scénarios, utilisez-vous un TagLib au lieu d'un modèle (et vice-versa)?

Answer 1

Il y a certainement un certain chevauchement, mais au-dessous sont plusieurs choses à penser. Une façon de penser à ce sujet est que modèle est comme une réutilisation au niveau de la méthode, alors que TagLibs sont plus commodes pour la réutilisation niveau de l'API.

• Modèles sont parfaits pour quand vous devez formater quelque chose de spécifique pour l'affichage. Par exemple, si vous blême pour afficher un objet de domaine d'une manière spécifique, il est généralement plus facile de le faire dans un modèle, puisque vous écrivez essentiellement juste HTML avec certains. Il est réutilisable, mais je pense que son réutilisabilité un peu limité. C'est à dire. si vous avez un modèle, vous souhaitez l'utiliser dans plusieurs pages, et non pas dans des centaines de pages.

• Par contre, taglibs est une unité plus petite de fonctionnalité, mais vous êtes plus susceptibles d'utiliser dans de nombreux endroits. Dans ce que vous êtes susceptible de concaténer des chaînes, donc si vous cherchez à créer une centaine de lignes de HTML, ils sont moins pratiques. Une caractéristique clé est taglibs permettent capacité d'injecter / interagir avec les services. Par exemple, si vous avez besoin d'un morceau de code qui appelle un service d'authentification et affiche l'utilisateur actuel, vous ne pouvez le faire que dans un TagLib. Vous n'avez pas à vous soucier de passer quoi que ce soit à la taglib dans ce cas - taglib partirez et le comprendre du service. Vous êtes également susceptible d'utiliser que dans beaucoup de pages, il est donc plus commode d'avoir un taglib qui n'a pas besoin de paramètres.

• Il y a aussi plusieurs types de taglibs, y compris ceux qui permettent vous itérer sur quelque chose dans la organe, conditionnel, etc - c'est pas vraiment possible avec les modèles. Comme je l'ai dit plus haut, un puits de fabrication artisanale bibliothèque taglib peut être utilisé pour créer une API réutilisable qui rend votre GSP le code plus lisible. A l'intérieur même * taglib.groovy vous pouvez avoir plusieurs définitions d'étiquette, de sorte que la différence est une autre - vous pouvez regrouper tous en une fois place et appel d'un taglib dans un autre.

De plus, gardez à l'esprit que vous pouvez appeler un modèle à l'intérieur d'un taglib, ou vous pouvez appeler taglibs withing modèles, de sorte que vous pouvez mélanger et assortir au besoin.

Espérons que cela il efface pour vous un peu, mais vraiment beaucoup de c'est ce concept est plus pratique pour le code et la fréquence sera réutilisée.

Answer 2

Pour nous ...

Un codeur est censé voir la logique spécifique de présentation d'objets dans le modèle, nulle part ailleurs.

Nous utilisons taglibs uniquement pour les éléments de page isolés, non liés à la logique métier du tout. En fait, nous essayons de minimiser leur utilisation: il est trop facile d'écrire la logique métier dans un taglib

.

Les modèles sont de façon classique pour aller; par exemple, ils prennent en charge Layouts (BTW, ils peuvent être nommés un troisième mécanisme)