Quando dovrei usare h: outputLink invece di h: commandLink?

129

Quando dovrei usare un <h:outputLink>invece di un <h:commandLink>?

Capisco che a commandLinkgenera un post HTTP; Immagino che outputLinkgenererà HTTP. Detto questo, la maggior parte del materiale tutorial JSF che ho letto utilizza commandLink(quasi?) Esclusivamente.

Contesto: sto implementando un piccolo progetto demo che mostra un collegamento di intestazione a una pagina utente, proprio come Stack Overflow ...

ha bisogno di più jquery

... e non sono sicuro se commandLink(forse usando ?faces-redirect=trueper la segnalabilità) o outputLinkè la scelta giusta.

jsf jsf-2

— Matt Ball
fonte

195

Il <h:outputLink>rendering di un <a>elemento HTML pienamente valido con l'URL corretto hrefnell'attributo che genera una richiesta GET con segnalibro. Non può richiamare direttamente un metodo di azione del bean gestito.

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

La <h:commandLink>rende un HTML <a>elemento con uno onclickscript che invia un modulo (nascosto) POST e grado di richiamare un metodo di azione bean gestito. Deve anche essere inserito in a <h:form>.

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

Il ?faces-redirect=trueparametro su <h:commandLink>, che attiva un reindirizzamento dopo il POST (secondo il modello Post-Redirect-Get ), migliora solo la segnalabilità della pagina di destinazione quando si fa effettivamente clic sul collegamento (l'URL non sarà più "uno dietro") , ma non cambia hrefl' <a>elemento dell'elemento in un URL completo. Rimane ancora #.

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

A partire da JSF 2.0, esiste anche il metodo <h:link>che può richiedere un ID di visualizzazione (risultato di un caso di navigazione) anziché un URL. Genererà anche un <a>elemento HTML con l'URL corretto in href.

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

Quindi, se è per la navigazione da pagina a pagina pura e aggiungibile ai segnalibri come il collegamento del nome utente SO, quindi utilizzare <h:outputLink>o<h:link> . Questo è anche meglio per il SEO poiché i robot di solito non codificano i moduli POST né il codice JS. Inoltre, UX verrà migliorato poiché le pagine sono ora aggiungibili ai segnalibri e l'URL non è più "uno dietro".

Se necessario, è possibile eseguire il processo di preelaborazione nel costruttore o @PostConstructdi un @RequestScopedo @ViewScoped @ManagedBeanche è collegato alla pagina di destinazione in questione. È possibile utilizzare @ManagedPropertyo <f:viewParam>per impostare i parametri GET come proprietà del bean.

Guarda anche:

— BalusC
fonte

No, non deve esserlo. Solo i UICommandcomponenti devono essere inseriti in un UIFormcomponente.

— BalusC,

Nessuno, in realtà. Generalmente, quando puoi, segui h:outputLinko h:linkper i link. SEO non dovrebbe essere sottovalutato. A proposito, per i bei URL simili a REST come qui su SO, dai un'occhiata a PrettyFaces .

— BalusC,

No, la differenza è che h:linkprende l'ID vista JSF (es. page) Come valore e h:outputLinkaccetta un URL reale (es. /page.xhtmlO /page.jsf, o altro a seconda della FacesServletmappatura) come valore. La codifica URL avviene comunque in entrambi i casi. Non c'è alcuna differenza tra il comportamento di rendering di EL nel testo del modello #{...}e h:outputText. Entrambi sfuggono alle entità XML predefinite (no, non è lo stesso della codifica URL). L' h:outputTextunica offre più attributi come id, styleClassecc, per controllare il componente e / o il markup.

— BalusC,

@BalusC Cosa intendi esattamente per "fullworthy HTML" nella prima riga della tua risposta?

— Geek,

@Geek: solo un punto per un <a>elemento HTML , niente di più, nessuna fantasia, nessun codice JS, ecc.

— BalusC

Vedo anche che il caricamento della pagina (prestazioni) richiede molto tempo utilizzando h: commandLink di h: link. h: il collegamento è più veloce rispetto a h: commandLink

— Ashok
fonte

Lo trovo difficile da credere. A parte il sentito / la tua stessa prova aneddotica, hai qualcosa a sostegno di ciò?

— Matt Ball,

@Matt: posso immaginare che sia più lento quando hai un link di navigazione POST all'interno di un modulo "God" in una pagina con ad esempio un datatable con> 1000 righe contenenti 3 campi di input per riga. Ma una pagina del genere ha comunque altri seri problemi :)

— BalusC