2
votes

JSF + Primefaces newbie. (using JSF 2.1, Primefaces 3.4.2)

I have a form that has an inner panelGroup that uses a Primefaces commandButton to fetch data to populate various form components. The partialSubmit gets around the validation issues of fields not yet populated so that works well. The page functions as intended but now I'm trying to tweak the implementation to be be 'cleaner'.

My question pertains to the JSF scoping I'm using for the backing bean the form is using. Using session scope, all is well but not when using request scoping. It is my understanding that both the 'final' submit (via another p:commandButton component) and this fetch button are both invoking a submit so that the response to either constitutes the completion of the request lifecycle. If I'm correct, it explains why I get (using requst scope) the following:
java.lang.IllegalStateException: Cannot create a session after the response has been committed

when using the fetch button.

But clearly this 'breaks' my intent for the fetch request to merely cause the form to use updated data via the bean.

So, am I correct in my understanding that any design pattern that has the use of an intermediate submission (via the partialSubmit="true" commandButton (ajax behavior is enabled by default) will require the use of at least session scoped backing beans? Ideally, a mechanism for having an implementation request versus a navigation level request would allow for these intermediate submits to be done within the context of 1 request. Or do I need to do some additional research? (get a JSF 2.x book rather than use my 1.2 copy?) MTIA for any feedback.

my fetch component:

<p:commandButton id="returningBtn" partialSubmit="true" value="Hit if returning" 
    process="nameInfo" actionListener="#{player.loadReturning}" update="registrationForm">
    <p:resetInput target="registrationForm" />
</p:commandButton>

my final submit:

<p:commandButton tabindex="0" id="SubmitButton" value="Register"
   action="#{player.register}" update="regPage"/>
1

1 Answers

3
votes

The partialSubmit gets around the validation issues of fields not yet populated so that works well.

No it doesn't do that. It only sends the input fields specified in process attribute to the server instead of all input fields of the current form. It's exactly the process attribute which tells which inputs needs to be processed (converted, validated and updated). The partialSubmit="true" merely reduces the network bandwidth and request parameter parsing overhead. See also PrimeFaces blog on the subject.


The page functions as intended but now I'm trying to tweak the implementation to be be 'cleaner'. My question pertains to the JSF scoping I'm using for the backing bean the form is using. Using session scope, all is well but not when using request scoping.

The session scope is indeed the wrong scope for forms. You need either the request or the view scope. If your form has a certain state which needs to be remembered across subsequent submits on the same form, then you need the view scope. See also How to choose the right bean scope?


java.lang.IllegalStateException: Cannot create a session after the response has been committed

This is recognizeable as a bug in Mojarra which is fixed in 2.1.8. See also Adding <h:form> causes java.lang.IllegalStateException: Cannot create a session after the response has been committed for several workarounds if you can't upgrade.


So, am I correct in my understanding that any design pattern that has the use of an intermediate submission (via the partialSubmit="true" commandButton (ajax behavior is enabled by default) will require the use of at least session scoped backing beans? Ideally, a mechanism for having an implementation request versus a navigation level request would allow for these intermediate submits to be done within the context of 1 request.

As said, you need the view scope.


Or do I need to do some additional research? (get a JSF 2.x book rather than use my 1.2 copy?)

Definitely. Not only is the view scope new since JSF2, but also many, many other things are done differently (read: more elegantly) in JSF2 as compared to JSF1. You can find several links to sane JSF2 resources at the bottom of our JSF wiki page.