I have RequestScoped bean because I’m redirecting the user from dataTable with records to edit page. In this dataTable I have delete buttons:
<p:column>
<p:commandButton update=":deleteNewsDialog" oncomplete="deleteNewsDlg.show()" icon="ui-icon-closethick">
<f:setPropertyActionListener value="#{news}" target="#{newsBean.news}" />
</p:commandButton>
</p:column>
And here is the dialog:
<p:confirmDialog id="deleteNewsDialog" message="Czy na pewno chcesz usunąć wiadomość o tytule "#{newsBean.news.title}"?"
header="Usuwanie wiadomości" severity="alert"
widgetVar="deleteNewsDlg" appendToBody="true">
<h:form>
<p:commandButton value="Usuń" actionListener="#{newsBean.delete}" update=":newsesTableForm:newsesTable, :newsesTableForm:newsGrowl"/>
<p:commandButton value="Anuluj" oncomplete="deleteNewsDlg.hide();"/>
</h:form>
</p:confirmDialog>
When newsBean.delete is fired, newsBean not longer exists so I get a lot of ugly validation exceptions. I have other pages like this with ViewScoped beans and there it is working like a charm. Help?
A request scoped bean has a lifetime of exactly one HTTP request/response. So retrieving the entire view with the form is already one HTTP request/response. The request scoped bean is trashed by end of the response. When you fire an ajax request on the view, then you’re essentially sending a new HTTP request. This will thus create a new request scoped bean which get trashed by end of HTTP response. So every ajax request on the same view get its own request scoped bean instance.
This is not what you want if you need to maintain data related to the view. You need to put the bean in the view scope instead. The bean will live as long as you’re interacting with the same view by ajax and return
nullorvoidin action listener methods. Note that when you return aString, even if empty, the view will be recreated and thus the view scoped bean will be trashed.See also: