ViewParam vs @ManagedProperty (value = "# {param.id}")

Qual è la differenza tra la definizione dei parametri di visualizzazione in questo modo:

<f:metadata>
  <f:viewParam name="id" value="#{someBean.id}"/>
</f:metadata>

E definendo la proprietà in ManagedBean in questo modo:

@ManagedProperty(value = "#{param.id}")
private Integer id;

<f:viewParam>:

• Imposta il valore solo durante la fase di aggiornamento dei valori del modello (poiché si estende UIInput).

• Il valore impostato non è disponibile durante @PostConstruct, quindi è necessario un ulteriore <f:event type="preRenderView" listener="#{bean.init}" />interno <f:metadata>per eseguire l'inizializzazione / precaricamento in base ai valori impostati. Poiché JSF 2.2 potresti usare <f:viewAction>per quello invece.

• Consente una conversione / convalida nidificata <f:converter>e <f:validator>più dettagliata. Anche un <h:message>può essere allegato.

• Può essere incluso come stringa di query GET utilizzando l' includeViewParamsattributo <h:link>o il includeViewParams=trueparametro di richiesta in qualsiasi URL.

• Può essere utilizzato su un @RequestScopedbean, ma richiede che lo sia @ViewScopedse si desidera che i parametri di visualizzazione sopravvivano a eventuali errori di convalida causati dai moduli racchiusi nella visualizzazione, altrimenti è necessario conservare manualmente tutti i parametri di richiesta per le richieste successive da parte <f:param>del comando componenti.

Esempio :

<f:metadata>
    <f:viewParam id="user_id" name="id" value="#{bean.user}"
        required="true" requiredMessage="Invalid page access. Please use a link from within the system."
        converter="userConverter" converterMessage="Unknown user ID."
    />
</f:metadata>
<h:message for="user_id" />

con

private User user;

e un @FacesConverter("userConverter"). Il richiamo della pagina tramite http://example.com/context/user.xhtml?id=123 passerà il idparametro attraverso il convertitore e imposterà l' Useroggetto come proprietà del bean.

@ManagedProperty:

• Imposta il valore immediatamente dopo la costruzione del bean.

• È disponibile il valore impostato durante il @PostConstructquale consente una facile inizializzazione / precaricamento di altre proprietà in base al valore impostato.

• Non consente la conversione / convalida dichiarativa in vista.

• La proprietà gestita di #{param}non è consentita sui bean con un ambito più ampio di quello della richiesta, quindi il bean deve esserlo @RequestScoped.

• Se si fa affidamento sulla presenza di una proprietà gestita #{param}nelle successive richieste POST, è necessario includerla come <f:param>nei UICommandcomponenti.

Esempio :

@ManagedProperty("#{param.id}")
private Long id;

private User user;

@EJB
private UserService userService;

@PostConstruct
public void init() {
    user = userService.find(id);
}

Ma si deve gestire la convalida te stesso ogni volta che userè nullper giocherellare con FacesContext#addMessage()o qualcosa del genere.

È possibile utilizzarli sia quando entrambi @PostConstructe includeViewParamssono obbligatori. Solo non sarai più in grado di applicare una conversione / convalida a grana fine.

Guarda anche:

• Per cosa possono essere utilizzati <f: metadata>, <f: viewParam> e <f: viewAction>?
• Comunicazione in JSF 2.0 - Elaborazione dei parametri di richiesta GET

2 altre differenze:

• @ManagedPropertyè utilizzabile solo con i bean gestiti da JSF, non con i bean gestiti da CDI ( @Named);
  • <f:viewParam> funziona solo con i parametri delle richieste GET.