Quand dois-je utiliser h: outputLink au lieu de h: commandLink?

129

Quand devrais-je utiliser un <h:outputLink>au lieu d'un <h:commandLink>?

Je comprends que a commandLinkgénère un message HTTP; Je suppose que outputLinkcela générera des HTTP. Cela dit, la plupart des didacticiels JSF que j'ai lus utilisent commandLink(presque?) Exclusivement.

Contexte: J'implémente un tout petit projet de démonstration qui montre un lien d'en-tête vers une page utilisateur, un peu comme Stack Overflow ...

a besoin de plus de jquery

... et je ne sais pas si commandLink(peut-être en utilisant ?faces-redirect=truepour la mise en signet) ou outputLinkest le bon choix.

jsf jsf-2 Matt Ball
la source

Réponses:

195

Le <h:outputLink>rend un <a>élément HTML digne de ce nom avec l'URL appropriée dans l' hrefattribut qui déclenche une requête GET pouvant être mise en signet. Il ne peut pas appeler directement une méthode d'action de bean géré.

<h:outputLink value="destination.xhtml">link text</h:outputLink>

Le <h:commandLink>rend un <a>élément HTML avec un onclickscript qui soumet un formulaire POST (masqué) et peut invoquer une méthode d'action de bean géré. Il doit également être placé dans un fichier <h:form>.

<h:form>
    <h:commandLink value="link text" action="destination" />
</h:form>

Le ?faces-redirect=trueparamètre sur le <h:commandLink>, qui déclenche une redirection après le POST (selon le modèle Post-Redirect-Get ), n'améliore la possibilité de signets de la page cible que lorsque le lien est réellement cliqué (l'URL ne sera plus "un derrière") , mais cela ne change pas le hrefde l' <a>élément pour être une URL complète. Il reste toujours #.

<h:form>
    <h:commandLink value="link text" action="destination?faces-redirect=true" />
</h:form>

Depuis JSF 2.0, il y a aussi le <h:link>qui peut prendre un ID de vue (un résultat de cas de navigation) au lieu d'une URL. Il générera également un <a>élément HTML avec l'URL appropriée au format href.

<h:link value="link text" outcome="destination" />

Donc, s'il s'agit d'une navigation pure et simple de page à page, comme le lien du nom d'utilisateur SO, utilisez <h:outputLink>ou <h:link>. C'est également mieux pour le référencement car les robots ne chiffrent généralement pas les formulaires POST ni le code JS. De plus, l'expérience utilisateur sera améliorée car les pages peuvent désormais être mises en signet et l'URL n'est plus "un derrière".

Si nécessaire, vous pouvez effectuer le travail de prétraitement dans le constructeur ou @PostConstructd'un @RequestScopedou @ViewScoped @ManagedBeanqui est attaché à la page de destination en question. Vous pouvez utiliser @ManagedPropertyou <f:viewParam>pour définir des paramètres GET comme propriétés de bean.

Voir également:

BalusC
la source
2
Non, ça ne doit pas être. Seuls les UICommandcomposants doivent entrer dans un UIFormcomposant.
BalusC
3
Aucun, en fait. Généralement, quand vous le pouvez, tenez-vous h:outputLink-en h:linkaux liens. Le référencement ne doit pas être sous-estimé. Au fait, pour de belles URL de type REST comme ici sur SO, jetez un œil à PrettyFaces .
BalusC
1
Non, la différence est que h:linkprend l'ID de vue JSF (par exemple page) comme valeur et h:outputLinkprend une URL réelle (par exemple /page.xhtmlou /page.jsf, ou autre selon votre FacesServletmappage) comme valeur. Le codage d'URL se produit de toute façon dans les deux cas. Il n'y a d'ailleurs aucune différence entre le comportement de rendu d'EL dans le texte du modèle #{...}et h:outputText. Les deux échappent aux entités XML prédéfinies (non, ce n'est pas la même chose que le codage d'URL). Les h:outputTextseules offres plus attribtues aiment id, styleClass, etc pour contrôler le composant et / ou le balisage.
BalusC
1
@BalusC Qu'entendez-vous exactement par «HTML complet» dans la première ligne de votre réponse?
Geek
1
@Geek: juste un <a>élément HTML au point , rien de plus, pas de fantaisie, pas de code JS, etc.
BalusC
4

Je vois également que le chargement de la page (performances) prend beaucoup de temps avec h: commandLink que h: link. h: link est plus rapide que h: commandLink

Ashok
la source
1
Je trouve cela difficile à croire. Hormis les ouï-dire / vos propres preuves anecdotiques, avez-vous quelque chose à l'appui?
Matt Ball
5
@Matt: J'imagine que c'est plus lent quand vous avez un lien de navigation POST dans un formulaire "Dieu" dans une page avec par exemple une table de données avec> 1000 lignes contenant 3 champs d'entrée par ligne. Mais une telle page a quand même d'autres problèmes sérieux :)
BalusC