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

Jaka jest różnica między definiowaniem parametrów widoku w następujący sposób:

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

I definiowanie właściwości w ManagedBean w następujący sposób:

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

<f:viewParam>:

• Ustawia wartość tylko podczas fazy aktualizacji wartości modelu (ponieważ jest rozszerzana UIInput).

• Ustawiona wartość nie jest dostępna w trakcie @PostConstruct, więc potrzebujesz dodatkowego <f:event type="preRenderView" listener="#{bean.init}" />wewnątrz, <f:metadata>aby wykonać inicjalizację / wstępne ładowanie w oparciu o ustawione wartości. Od JSF 2.2 możesz <f:viewAction>zamiast tego użyć .

• Pozwala na zagnieżdżoną <f:converter>i <f:validator>bardziej szczegółową konwersję / walidację. Nawet <h:message>można dołączyć.

• Może być uwzględniony jako ciąg zapytania GET przy użyciu includeViewParamsatrybutu <h:link>lub includeViewParams=trueparametru żądania w dowolnym adresie URL.

• Może być używany na @RequestScopedfasoli, ale wymaga, aby komponent bean był, @ViewScopedjeśli chcesz, aby parametry widoku przetrwały wszelkie błędy walidacji spowodowane przez formularze zawarte w widoku; w przeciwnym razie musisz ręcznie zachować wszystkie parametry żądania dla kolejnych żądań za <f:param>pomocą polecenia składniki.

Przykład :

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

z

private User user;

i @FacesConverter("userConverter"). Wywołanie strony przez http://example.com/context/user.xhtml?id=123 spowoduje przekazanie idparametru przez konwerter i ustawienie Userobiektu jako właściwości fasoli.

@ManagedProperty:

• Ustawia wartość bezpośrednio po skonstruowaniu fasoli.

• Wartość ustawiona jest dostępna, @PostConstructco umożliwia łatwą inicjalizację / wstępne ładowanie innych właściwości w oparciu o ustawioną wartość.

• Nie zezwala na deklaratywną konwersję / walidację w widoku.

• Właściwość zarządzana #{param}nie jest dozwolona w przypadku komponentów bean o szerszym zakresie niż zakres żądania, więc komponent bean musi być @RequestScoped.

• Jeśli polegasz na właściwości zarządzanej, #{param}która jest obecna w kolejnych żądaniach POST, musisz ją uwzględnić tak, jak <f:param>w UICommandkomponentach.

Przykład :

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

private User user;

@EJB
private UserService userService;

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

Ale trzeba zarządzać walidacji siebie ilekroć userjest nullprzez bawiąc się FacesContext#addMessage()czy coś.

Państwo mogą z nich korzystać zarówno gdy oba @PostConstructi includeViewParamssą obowiązkowe. Nie będziesz już tylko mógł zastosować szczegółowej konwersji / walidacji.

Zobacz też:

• Do czego można użyć <f: metadata>, <f: viewParam> i <f: viewAction>?
• Komunikacja w JSF 2.0 - Przetwarzanie parametrów żądania GET

2 inne różnice:

• @ManagedPropertyjest użyteczne tylko z fasolami zarządzanymi przez JSF, a nie z fasolami zarządzanymi przez CDI ( @Named);
  • <f:viewParam> działa tylko z parametrami żądań GET.