ViewParam vs @ManagedProperty (valor = “# {param.id}”)

¿Cuál es la diferencia entre definir View Params así:

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

Y definir la propiedad en ManagedBean así:

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

<f:viewParam>:

• Establece el valor solo durante la fase de actualización de valores del modelo (ya que se extiende UIInput).

• El valor establecido no está disponible durante @PostConstruct, por lo que necesita un <f:event type="preRenderView" listener="#{bean.init}" />interior adicional <f:metadata>para realizar la inicialización / precarga en función de los valores establecidos. Desde JSF 2.2, podría usarlo <f:viewAction>para eso.

• Permite una conversión / validación anidada <f:converter>y <f:validator>más detallada. Incluso <h:message>se puede adjuntar.

• Puede incluirse como una cadena de consulta GET mediante el includeViewParamsatributo <h:link>o el includeViewParams=trueparámetro de solicitud en cualquier URL.

• Se puede usar en un @RequestScopedbean, pero requiere que el bean lo esté @ViewScopedsi desea que los parámetros de la vista sobrevivan a las fallas de validación causadas por los formularios incluidos en la vista; de lo contrario, debe retener manualmente todos los parámetros de solicitud para las solicitudes posteriores <f:param>en el comando componentes.

Ejemplo :

<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;

y un @FacesConverter("userConverter"). Invocar la página por http://example.com/context/user.xhtml?id=123 pasará el idparámetro a través del convertidor y establecerá el Userobjeto como una propiedad de bean.

@ManagedProperty:

• Establece el valor inmediatamente después de la construcción del bean.

• El valor establecido está disponible durante el @PostConstructcual permite una fácil inicialización / precarga de otras propiedades según el valor establecido.

• No permite la conversión / validación declarativa a la vista.

• La propiedad administrada de #{param}no está permitida en beans con un alcance más amplio que el alcance de la solicitud, por lo que el bean debe serlo @RequestScoped.

• Si confía en una propiedad administrada de #{param}estar presente en las solicitudes POST posteriores, debe incluirla como <f:param>en los UICommandcomponentes.

Ejemplo :

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

private User user;

@EJB
private UserService userService;

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

Pero tienes que gestionar la validación tú mismo siempre userque nulljuegues con FacesContext#addMessage()algo o algo.

Usted puede utilizar los dos cuando ambos @PostConstructy includeViewParamsson obligatorios. Solo ya no podrá aplicar una conversión / validación detallada.

Ver también:

• ¿Para qué se pueden usar <f: metadata>, <f: viewParam> y <f: viewAction>?
• Comunicación en JSF 2.0 - Procesando parámetros de solicitud GET

2 otras diferencias:

• @ManagedPropertysolo se puede usar con beans administrados por JSF, no con beans administrados por CDI ( @Named);
  • <f:viewParam> funciona solo con parámetros de solicitudes GET.