ViewParam против @ManagedProperty (значение = «# {param.id}»)

В чем разница между определением параметров просмотра следующим образом:

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

И определяем свойство в ManagedBean следующим образом:

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

<f:viewParam>:

• Устанавливает значение только на этапе обновления значений модели (так как оно расширяется UIInput).

• Установленное значение недоступно во время @PostConstruct, поэтому вам понадобится дополнительная <f:event type="preRenderView" listener="#{bean.init}" />внутренняя часть <f:metadata>для инициализации / предварительной загрузки на основе установленных значений. Начиная с JSF 2.2, вы можете использовать <f:viewAction>вместо этого.

• Позволяет выполнять вложенное <f:converter>и <f:validator>более детальное преобразование / проверку. Даже <h:message>может быть приложена.

• Может быть включен как строка запроса GET с использованием includeViewParamsатрибута <h:link>или includeViewParams=trueпараметра запроса в любом URL-адресе.

• Может использоваться с @RequestScopedкомпонентом, но для него требуется, чтобы этот компонент был, @ViewScopedесли вы хотите, чтобы параметры представления пережили любые ошибки проверки, вызванные формами, включенными в представление, в противном случае вам нужно вручную сохранить все параметры запроса для последующих запросов <f:param>в команде составные части.

Пример :

<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" />

с участием

private User user;

и ан @FacesConverter("userConverter"). Вызов страницы с помощью http://example.com/context/user.xhtml?id=123 передаст idпараметр через преобразователь и установит Userобъект как свойство bean-компонента.

@ManagedProperty:

• Устанавливает значение сразу после создания bean-компонента.

• Доступно установленное значение, @PostConstructчто позволяет легко инициализировать / предварительно загрузить другие свойства на основе установленного значения.

• Не допускает декларативного преобразования / проверки в поле зрения.

• Управляемое свойство #{param}недопустимо для bean-компонентов с более широкой областью, чем область запроса, поэтому bean-компонент должен быть @RequestScoped.

• Если вы полагаетесь на то, что управляемое свойство #{param}присутствует в последующих запросах POST, вам необходимо включить его, как <f:param>в UICommandкомпоненты.

Пример :

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

private User user;

@EJB
private UserService userService;

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

Но вы должны управлять Validation себя всякий раз , когда userэто nullот возиться с FacesContext#addMessage()или что - то.

Вы можете использовать их оба, когда оба @PostConstructи includeViewParamsявляются обязательными. Вы только больше не сможете применять детализированное преобразование / проверку.

Смотрите также:

• Для чего можно использовать <f: metadata>, <f: viewParam> и <f: viewAction>?
• Связь в JSF 2.0 - Обработка параметров запроса GET

2 других отличия:

• @ManagedPropertyможно использовать только с bean-компонентами, управляемыми JSF, но не с bean-компонентами, управляемыми CDI ( @Named);
  • <f:viewParam> работает только с параметрами GET-запросов.