Come navigare in JSF? Come rendere l’URL riflette la pagina corrente (e non quella precedente)

Attualmente sto imparando JSF ed ero piuttosto stupito e perplesso quando ho capito che ogni volta che usiamo , il comportamento standard di JSF è di mostrarmi sempre l’URL della pagina precedente nel browser, al contrario dell’URL di la pagina corrente .

Capisco che questo abbia a che fare con il modo in cui JSF invia sempre un modulo alla stessa pagina e quindi restituisce semplicemente la pagina che il controllore restituisce al browser che non sa che la posizione della pagina è cambiata.

Sembra che la JSF sia stata in giro abbastanza a lungo che ci debba essere un modo pulito e solido per affrontarlo. Se è così, ti dispiacerebbe condividere?

Ho trovato vari soluzioni alternative, ma purtroppo nulla sembra una soluzione reale.

  • Accetta semplicemente che l’URL sia fuorviante.
  • Aggiungi "?faces-redirect=true" al valore di ritorno dell’azione di ogni bean e poi
    • capire come sostituire @RequestScoped con qualcos’altro (Flash Scopes, conversazione CDI, @SessionScoped, …).
    • accetta di avere due round round HTTP per ogni azione dell’utente.
  • Utilizzare un metodo (es. Libreria di terze parti o codice personalizzato) per hide il nome della pagina nell’URL, utilizzando sempre lo stesso URL generico per ogni pagina.

Se "?faces-redirect=true" è buono come si ottiene, c’è un modo per configurare un’intera applicazione per trattare tutte le richieste in questo modo?

Infatti, JSF essendo una struttura basata su moduli con targeting per framework MVC invia il modulo POST allo stesso URL di dove è stata richiesta la pagina con il . Puoi confermarlo guardando l’URL

dell’output HTML generato. Questo è nei termini di sviluppo web caratterizzati come postback . Per impostazione predefinita, una navigazione su un postback non causa una nuova richiesta al nuovo URL, ma carica la pagina di destinazione come contenuto della risposta. Questo è davvero fonte di confusione quando si desidera semplicemente la navigazione da pagina a pagina.

In generale, l’approccio corretto in materia di navigazione / reindirizzamento dipende dalle esigenze aziendali e dall’idempotenza (leggi: “bookmarkability”) della richiesta.

  • Se la richiesta è idempotente, è sufficiente utilizzare un modulo / collegamento GET anziché il modulo POST (ovvero utilizzare

    , o invece di e ).
    Ad esempio, navigazione da pagina a pagina, modulo di ricerca simile a Google, ecc.

  • Se la richiesta non è idempotente, è sufficiente mostrare i risultati in modo condizionale nella stessa vista (cioè restituire null o void e utilizzare ad esempio e / o rendered ).
    Ad esempio, inserimento / modifica dati, procedura guidata multi-passo, finestra di dialogo modale, modulo di conferma, ecc.

  • Se la richiesta non è idempotente, ma la pagina di destinazione è idempotente, è sufficiente inviare un reindirizzamento dopo il POST (es. Restituire esito con ?faces-redirect=true o ).
    Ad esempio, mostrando l’elenco di tutti i dati dopo aver eseguito correttamente la modifica, redirect dopo l’accesso, ecc.

Si noti che la semplice navigazione da pagina a pagina è in genere idempotente ed è qui che molti avviatori JSF falliscono abusando di collegamenti / pulsanti di comando per quello e quindi si lamentano in seguito che gli URL non cambiano. Si noti inoltre che i casi di navigazione sono utilizzati molto raramente in applicazioni del mondo reale sviluppate rispetto a SEO / UX ed è qui che molti tutorial JSF falliscono lasciando che i lettori credano diversamente.

Si noti inoltre che l’utilizzo di POST non è assolutamente “più sicuro” di GET perché i parametri della richiesta non sono immediatamente visibili nell’URL. Sono ancora visibili nel corpo della richiesta HTTP e sono ancora manipolabili. Quindi non c’è assolutamente alcun motivo per preferire il POST per le richieste di identificazione in nome della “sicurezza”. La vera sicurezza sta nell’usare HTTPS anziché HTTP e nel verificare i metodi di servizio commerciale se l’utente attualmente loggato è autorizzato a interrogare l’ quadro X, o a manipolare l’ quadro X, ecc. Un quadro di sicurezza decente offre annotazioni per questo.

Guarda anche:

  • Qual è la differenza tra reindirizzamento e navigazione / avanti e quando usare cosa?
  • JSF implicito vs navigazione esplicita
  • Bookmarkability tramite la funzione View Parameters
  • Per cosa possono essere usati , e ?
  • Quando dovrei usare h: outputLink invece di h: commandLink?
  • Creazione di pagine di dettaglio master per quadro, come collegarle e quale ambito di bean scegliere
  • Mantenere i parametri della stringa di query di richiesta GET sul modulo JSF submit
  • Passa un object tra i bean @ViewScoped senza utilizzare i parametri GET