J'ai récemment commencé à utiliser JSF 2.0 avec Facelets et j'ai été intrigué par les nouveaux composants composites connaissant les <ui:include>techniques existantes et d'autres techniques de modélisation proposées par Facelets 1.x.

Quelle est la différence entre ces approches? Fonctionnellement, ils semblent offrir à peu près la même chose: <ui:param>vs <cc:attribute>, <ui:insert>+ <ui:define>vs fichiers de balises, réutilisation des modèles existants. Y a-t-il autre chose que la syntaxe et la spécification d'interface claire dans le cas de composants composites? Les performances pourraient-elles différer?

Quelle est la différence entre ces approches?

Modèles de facettes

Utilisez Facelet modèles (comme dans <ui:composition>, <ui:include>et <ui:decorate>) si vous voulez diviser les principaux fragments de mise en page dans les modèles reuseable. Par exemple, en-tête, menu, contenu, pied de page, etc.

Exemples:

• Comment inclure un autre XHTML dans XHTML en utilisant des facelets JSF 2.0?
• Quelle est la vraie différence conceptuelle entre ui: decorate et ui: include?
• Comment personnaliser h: head lors de l'utilisation de ui: composition template?
• Comment changer les éléments d'en-tête d'une page lors de l'utilisation de l'interface utilisateur: composition
• Comment ajax-actualiser dynamique inclure du contenu par menu de navigation? (JSF SPA)

Fichiers de balises Facelet

Utilisez des fichiers de balises Facelet si vous souhaitez disposer d'un groupe de composants réutilisable afin d'éviter / minimiser la duplication de code. Par exemple, un groupe de composants étiquette + entrée + message. La principale différence avec les composants composites est que la sortie d'un fichier de balises Facelet ne représente pas un seul UIComponentet peut dans certaines circonstances être la seule solution lorsqu'un composant composite ne suffit pas. Généralement, avoir un <ui:include>avec un ou plusieurs <ui:param>qui transmet une propriété de bean géré (et donc pas une valeur codée en dur) est un signal que le fichier d'inclusion peut mieux être un fichier de balise.

Exemples:

• Comment créer une balise Facelets personnalisée?
• Comment faire une grille de composant composite JSF?
• Comment créer un composant composite pour une colonne datable?
• Primefaces outputLabel pour composant composite

Composants composites

Utilisez des composants composites si vous souhaitez créer une personnalisation unique et réutilisable UIComponentavec une seule responsabilité à l'aide de XML pur. Un tel composant composite se compose généralement d'un ensemble de composants existants et / ou HTML et est rendu physiquement en tant que composant unique et est censé être lié à une seule propriété de bean. Par exemple, un composant qui représente une java.util.Datepropriété unique par 3 <h:selectOneMenu>composants dépendants , ou un composant qui combine <p:fileUpload>et <p:imageCropper>en un seul <my:uploadAndCropImage>référençant une seule com.example.Imageentité personnalisée en tant que propriété.

Exemples:

• Notre page wiki sur les composants composites
• Le code BalusC: composant composite avec plusieurs champs de saisie
• Diviser java.util.Date sur deux champs h: inputText représentant l'heure et la minute avec f: convertDateTime
• Sélectionnez tous les éléments dans Multiple SelectManyCheckBox avec des identifiants dynamiques
• Extension du composant commandLink JSF
• Éviter les identifiants en double lors de la réutilisation de compositions de facelets dans le même conteneur de dénomination

Composants personnalisés

Utilisez un composant personnalisé chaque fois que la fonctionnalité ne peut pas être obtenue avec des fichiers de balises Facelet ou des composants composites, en raison du manque de prise en charge dans l'ensemble de composants standard / disponible. Des exemples peuvent être trouvés partout dans le code source des bibliothèques de composants open source telles que PrimeFaces et OmniFaces .

Gestionnaires de balises

Lorsque vous souhaitez contrôler la construction de l'arborescence des composants JSF au lieu du rendu de la sortie HTML, vous devez utiliser un gestionnaire de balises au lieu d'un composant.

Exemples:

• Composant Facelet personnalisé dans JSF
• Comment puis-je accéder au contenu d'un élément créé avec <ui: define> par programmation?
• Rendu conditionnel dans le tagfile selon que l'attribut est spécifié ou non
• Effectuer une redirection, lorsque la conversion / validation associée aux paramètres de requête échoue

Exemples de projets

Voici quelques exemples de projets qui utilisent toutes les techniques mentionnées ci-dessus.

• Application Java EE Kickoff ( modèles - comprend - tagfiles - composite )
• Vitrine OmniFaces ( modèles - comprend - tagfiles - composite )

Les performances pourraient-elles différer?

Techniquement, le problème de performance est négligeable. Le choix doit être fait en fonction des exigences fonctionnelles concrètes et du degré final d'abstraction, de réutilisabilité et de maintenabilité de la mise en œuvre. Chaque approche a ses propres objectifs et limites bien définis.

Les composants composites ont cependant une surcharge importante lors de la création / restauration de la vue (en particulier: lors de l'enregistrement / de la restauration de l'état de la vue). Et, dans les anciennes versions de Mojarra, les composants composites avaient des problèmes de performances avec l'attribution de valeurs par défaut, ce problème est déjà résolu depuis la version 2.1.13. De plus, Mojarra avait une fuite de mémoire quand a <cc:attribute method-signature>est utilisé pour les expressions de méthode, fondamentalement, tout l'arborescence des composants est re-référencée dans la session HTTP, ce problème est corrigé depuis 2.1.29 / 2.2.8. La fuite de mémoire peut être contournée dans les anciennes versions 2.1 comme ci-dessous:

<context-param>
    <param-name>com.sun.faces.serializeServerState</param-name>
    <param-value>true</param-value>
</context-param>

Ou dans les anciennes versions 2.2 comme ci-dessous:

<context-param>
    <param-name>javax.faces.SERIALIZE_SERVER_STATE</param-name>
    <param-value>true</param-value>
</context-param>

Pourtant, lorsque vous avez relativement "beaucoup" de composants composites et que vous avez javax.faces.STATE_SAVING_METHOD choisi client, alors les performances seront pénibles. N'abusez pas des composants composites si vous voulez simplement les fonctionnalités de base qui sont déjà possibles avec un simple fichier d'inclusion ou un fichier de balise. N'utilisez pas la facilité de configuration (lire: aucun *.taglib.xmlfichier nécessaire) comme excuse pour préférer les composants composites aux fichiers de balises.

Lorsque vous utilisez Mojarra 2.2.10 ou une version antérieure, n'oubliez pas de désactiver la période de rafraîchissement relativement courte des Facelets pour le mode production:

<context-param>
    <param-name>javax.faces.FACELETS_REFRESH_PERIOD</param-name>
    <param-value>-1</param-value>
</context-param>

N'utilisez pas ce paramètre pour le développement, sinon vous devez redémarrer tout le serveur pour que les modifications des fichiers Facelets soient reflétées! Mojarra 2.2.11 et plus récent, et MyFaces est déjà défini par défaut sur -1quand javax.faces.PROJECT_STAGEn'est pas défini sur Development.