Was ist der Unterschied zwischen der Definition von Ansichtsparametern wie folgt:
<f:metadata>
<f:viewParam name="id" value="#{someBean.id}"/>
</f:metadata>
Und definieren Sie die Eigenschaft in der ManagedBean folgendermaßen:
@ManagedProperty(value = "#{param.id}")
private Integer id;
Antworten:
<f:viewParam>::Legt den Wert nur während der Phase der Aktualisierung der Modellwerte fest (da er erweitert wird UIInput).
Der eingestellte Wert ist während nicht verfügbar @PostConstruct, daher benötigen Sie einen zusätzlichen Wert <f:event type="preRenderView" listener="#{bean.init}" />innerhalb der, <f:metadata>um die Initialisierung / Vorladung basierend auf den eingestellten Werten durchzuführen. Seit JSF 2.2 können Sie <f:viewAction>stattdessen dafür verwenden.
Ermöglicht verschachtelte <f:converter>und <f:validator>feinkörnigere Konvertierung / Validierung. Sogar ein <h:message>kann angebracht werden.
Kann als GET-Abfragezeichenfolge mit dem includeViewParamsAttribut <h:link>oder dem includeViewParams=trueAnforderungsparameter in einer beliebigen URL eingefügt werden.
Kann für eine @RequestScopedBean verwendet werden, erfordert jedoch die Bean, @ViewScopedwenn die Ansichtsparameter alle Validierungsfehler überleben sollen, die durch in der Ansicht enthaltene Formulare verursacht werden. Andernfalls müssen Sie alle Anforderungsparameter für die nachfolgenden Anforderungen von <f:param>im Befehl manuell beibehalten Komponenten.
Beispiel :
<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" />
mit
private User user;und ein @FacesConverter("userConverter"). Wenn Sie die Seite über http://example.com/context/user.xhtml?id=123 aufrufen, wird der idParameter durch den Konverter geleitet und das UserObjekt als Bean-Eigenschaft festgelegt.
@ManagedProperty::Legt den Wert unmittelbar nach der Konstruktion der Bohne fest.
Der eingestellte Wert ist verfügbar, während @PostConstructdessen andere Eigenschaften basierend auf dem eingestellten Wert einfach initialisiert / vorgeladen werden können.
Ermöglicht keine deklarative Konvertierung / Validierung im Blick.
Die verwaltete Eigenschaft von #{param}ist für Beans mit einem breiteren Bereich als dem Anforderungsbereich nicht zulässig, daher muss dies der Bean sein @RequestScoped.
Wenn Sie sich darauf verlassen, dass eine verwaltete Eigenschaft #{param}in den nachfolgenden POST-Anforderungen vorhanden ist, müssen Sie sie wie <f:param>in den UICommandKomponenten einschließen .
Beispiel :
@ManagedProperty("#{param.id}")
private Long id;
private User user;
@EJB
private UserService userService;
@PostConstruct
public void init() {
user = userService.find(id);
}Aber Sie müssen die Validierung selbst verwalten, wann immer Sie userdamit nullherumspielen FacesContext#addMessage()oder so.
Sie können beide verwenden, wenn beide @PostConstructund includeViewParamsobligatorisch sind. Sie können nur noch keine feinkörnige Konvertierung / Validierung mehr anwenden.
@ManagedPropertyeinen Anforderungsparameter unmöglich macht.
<f:event type="preRenderView">oder in der kommenden JSF 2.2 aufgerufen wird <f:viewAction>.
2 weitere Unterschiede:
@ManagedPropertykann nur mit von JSF verwalteten Beans verwendet werden, nicht mit von CDI ( @Named) verwalteten Beans ;
<f:viewParam> funktioniert nur mit Parametern von GET-Anforderungen.