Java Server Faces O'Reilly cap 9 - Controlling Navigation

9.1 Moving Between JSF Views

Questa è la visualizzazione standard per i link che crea un elemento di link normale in html

<h:outputLink value="prefUser.faces">
    <h:outputText value="Preferences" />
  </h:outputLink>

Se si vogliono passare i parametri bisogna annidare l'elemento <f:param> vedere l'appendice A per maggiori dettagli.
Navigare attraverso i link diretti è semplice e sufficiente in molti casi ma non quando l'input dell'utente deve essere processato prima di muoversi sulla pagina selezionata.

Vediamo le regole di navigazione da definire nel faces-config.xml:

<faces-config>
  ...
  <navigation-rule>
    <from-view-id>/expense/stage1/prefUser.jsp</from-view-id>
    <navigation-case>
      <from-action>#{userHandler.updateProfile}</from-action>
      <from-outcome>success</from-outcome>
      <to-view-id>/expense/stage1/prefLang.jsp</to-view-id>
    </navigation-case>
  </navigation-rule>
  ...
</faces-config>

Un elemento navigation rule contiene sotto elementi che dichiarano quando la regola viene applicata e quando bisogna fare lo switch. L'elemento <from-view-id> è opzionale se è specificato deve essere un identificatore di vista completo (deve esserci il path della pagina jsp o altro tipo di pagina), oppure un prefisso identificatore /expense/stage1/* che mathca con tutti gli identificatori di vista che iniziano con /expense/stage1/. Se <from-view-id> è omesso le regole matchano con tutti gli identificatori di vista.
Se più di un <navigation-rule> matcha l'elemento <from-view-id> tutti sono considerati dal navigation handler.
Uno o più <navigation-case> dichiarano come trattare casi differenti con il matching view. L'elmento <from-action> è opzionale e può essere usato per limitare la regola da applicare solo agli outcome da alcuni metodi specificati. L'elemento <to-view-id> è mandatorio e JSF switcha alla vista specificata quando trova un match.
Vediamo l'esempio 9.1 di cui vi è il codice di faces-config.xml nel blocco sopra, quando viene cliccato il bottone Next viene lanciata il metodo updateProfile() che restituisce il valore di outcome "success". Questo matcha la regola definita per la questa vista così JSF usa prefLang.jsp per renderizzare la risposta, ci si sposta quindi a questa da prefUser.jsp dove si era prima di cliccare su next.

Per il bottone di Cancel, si specifica un valore letterale di "cancel" invece un action method. Questo viene in aiuto quando si vuole solo guardare lo switch a una nuova vista, senza processare nessun input. Ecco la differenza tra i due tag

<h:commandButton value="Next" action="#{userHandler.updateProfile}" />
<h:commandButton value="Cancel" immediate="true" action="cancel" />

JSF usa il valore letterale solo come si usa un outcome sa un metodo di action per osservare un matching in una navigation rule. Nel blocco sotto vi è la regola che matcha.
<navigation-rule>
    <from-view-id>/expense/stage1/*</from-view-id>
    <navigation-case>
      <from-outcome>cancel</from-outcome>
      <to-view-id>/expense/stage1/menuArea.jsp</to-view-id>
      <redirect/>
    </navigation-case>
  </navigation-rule>

Da notare che si usa un prefisso per il <from-view-id> così la regola viene applicata al bottone di cancel in tutte e tre le viste.
Il valore immediate="true" nel bottone indica che nessuna validazione o model updates verrano presi quando l'utente clicca nel bottone di Cancel.

9.1.1 Choosing Between Redirect and Direct Rendering

Nel blocco precedente si vede usato un elemento di <redirect> vuoto con l'elemento di <navigation-case> per il bottone di Cancel. Questo è un elemento opzionale che dice a JSF di mandare un una risposta di redirect che invita il browser alla nuova pagina invece di quella che lui aveva richiesto (di quest'ultima frase non sono sicuro, asks the browser to request the specified view instead of rendering it as the response to the current request).

La differenza tra una risposta di redirect e un rendering diretto di una nuova vista è quello che con una risposta di redirect il browser modifica il suo campo indirizzo e mostra l'url della nuova vista, invece con il rendering diretto il campo indirizzo rimane invariato. Il ricaricamento e l'aggiunta di segnalibri (bookmarking) vengono applicati al vecchio indirizzo.

Come decidere quale usare? Il rendering diretto è sempre più veloce, così potrebbe essere sempre scelta come prima possibilità. Ma dato che la url rimane riferita alla vecchia vista bisogna pensare cosa accade se l'utente effettua un reload o un bookmark , se questo causa qualche problema considerare invece una risposta di redirect.

9.1.2 Using a Panel Component for Layout

L'esempio 9.3 e 9.4 seguono lo stesso pattern che abbiamo visto precedentemente. Il cambiamento è quello di usare l'elemento <h:panelGrid columns="2"> per effettuare il layout. Questo poi in fase di costruzione della pagina web viene tradotto con delle tabelle.

9.2 Returning a Non-JSF View Response

continuare da qui se lo si ritiene utile

jsf
Salvo diversa indicazione, il contenuto di questa pagina è sotto licenza Creative Commons Attribution-ShareAlike 3.0 License