Strange behavior in PF greater than 6.0.6

[krasig]

Hi all.
We are trying to migrate from Richfaces to Primefaces, but we have a very strange problem and any help is welcome.

Imagine a simple page with this content:

...

Code: Select all

 
        <h:form id="myform">
		<a4j:commandButton id="aaa" action="#{testBean.init()}"	oncomplete="alert(#{testBean.counter});"
			render="test" value="aaaa"/>
			<h:outputText id="test" value="#{testBean.counter}"/>
	</h:form>

..
in bean we have:

Code: Select all

public void init(){
		setShowModal(true);
		counter++;
	}
	public int getCounter() {
		return counter;
	}

	public void setCounter(int counter) {
		this.counter = counter;
	}

So, when you click on a button it triggers action init() who increment variable "counter". Next is ncomplete="alert(#{testBean.counter});" and finally outputText shows incremented value of "counter".


So with PrimeFaces later than 6.0.6 "oncomplete" and outputText shows different values.
As a matter of fact, oncomplete returns the value before incrementation.
This mean that oncomplete is triggered before action init().

The strange is, that PrimeFaces.jar is included in the project, but it is not used on the page.

Is this a bug or feature?

[Miguel Cubells]

I think you have some misunderstanding on how the Ajax works, no matter if RichFaces, PrimeFaces or plain Ajax.
oncomplete is a javascript function, and its content is rendered when the page is first loaded, and NEVER changes.

So, if your counter Java variable is 0 at the beginning, for example, then the output will render oncomplete="alert(0)" , and it will NEVER change again, unless you re-render the command button itself again. As I believe you are not doing so, I bet you can click the command button thousands of times, but the javascript oncomplete alert will always display 0.

However, the output of the outputText reflects the correct value, because you are updating it with the "render" attribute each time you click the button. In other words, the HTML of the output text is being replaced with each Ajax call, which gets the correct value from the Bean.

What you want to achieve could be done by using the PrimeFace's RequestContext.execute() from the bean, once the counter has been updated.

[hwaUser]

I know that this issue is quite old, but maybe some one else came across this problem as well and found a solution.

The example @krasig describes, definitively worked in with PF 6.0, at least if the a4j:commandButton rendered itself after the ajax call.

Code: Select all

<h:form id="myform">
		<a4j:commandButton id="aaa" action="#{testBean.init()}"	oncomplete="alert(#{testBean.counter});"
			render="test aaa" value="aaaa"/>
			<h:outputText id="test" value="#{testBean.counter}"/>
	</h:form>

In this case the oncomplete function had also been updated and executed afterwards. This means in PF6.0 the alert showed the new incremented value.

With never PF versions (I'm testing with 6.2), the oncomplete function is executed first and updated afterwards.

This is a problem for me as I often used the following pattern in RF, which does not work any longer using PF6.2

Code: Select all

<a4j:commandButton id="aaa" action="#{testBean.init()}"	
		oncomplete="
		if (#{facesContext.maximumSeverity}) 
		{ /*handle the error case*/
		} else {
		/*handle the success case.*/
		}"
		render="test aaa" value="aaaa"/>

[hwaUser]

I know that the original post is a bit old, but I wonder if someone else is also experiencing the problem @krasig described.

The example he posts definitively works in PF 6.0, at least if the button renders itself.

Code: Select all

  <h:form id="myform">
	<a4j:commandButton id="aaa" action="#{testBean.init()}"	oncomplete="alert(#{testBean.counter});"
		render="test aaa" value="aaaa"/>
	<h:outputText id="test" value="#{testBean.counter}"/>
</h:form>

With PF 6.0 the alert dialog shows the new incremented value. This means the oncomplete function was updated by ajax request, and executed afterwards.

However in later versions of PF (I'm testing with PF6.2), the behavior changed. Now the alert window shows the counter value before it was updated.
This behavior irritates me as a new PF versions affects the behavior of RF.

I was trusting in always getting up to date data in the oncomplete functions as I often used constructs like:

Code: Select all

<a4j:commandButton id="aaa" action="#{testBean.init()}"	
	oncomplete="
	if(#{facesContext.maximumSeverity==null}) {
		/* Handle the logical success state. */
	} else {
		/* Handle the logical error state. */
	}
	"
	render="test aaa" value="aaaa"/>

Maybe the PF team has an idea what had changed and how to get back the old behavior.

[Melloware]

I didn't take a deep dive into this but one of the major changes in PF 6.2 was going from Jquery 1.x to the latest Jquery 3.X which is what a lot of the Ajax code is all based around. So its possible something changed in Jquery.

Also what version of JSF are you using?

[hwaUser]

First of all, I want to apologize for the double post - I recognized too late that posts are checked by a moderator and published afterwards.

Regarding my tests - I tested with JSF 2.2 and JSF 2.3.

As far as I could figure out the problem has nothing to do with the versions of JQuery used, but is caused by the behavior of the server side.

With Primefaces 6.0, the content of the Richfaces-'oncomplete' method is being prepared in the RENDER_RESPONSE phase, which is the behavior I know and expect. I can see this in the debugger.
With using Primefaces 6.2, I see that the Richfaces-'oncomplete' method is no longer prepared (rendered) in the RENDER_RESPONSE phase, but in the APPLY_REQUEST_VALUES Phase, and therefore it is rendered with outdated data.

I suppose the changes which cause the new behavior are not related to Primefaces 6.2 but already to Primefaces 6.0.6, as @krasig reported.

[hwaUser]

The problem described in this ticket, arises due to an unlucky cooperation between PrimeFaces 6.0.x and Richfaces 4.5.
The trigger point is the modified PrimeFaces PhaseListener (org.primefaces.application.resource.DynamicResourcesPhaseListener), which lets RichFaces run into an error condition.

The bug has to be corrected on RichFaces side.
See also: https://github.com/albfernandez/richfaces/issues/25