You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Jon Bionda <jb...@csdcsystems.com> on 2013/04/01 23:16:25 UTC
Having a problem with MyFaces 2.1.10 (and 2.1.11) commandButton
submit *AFTER* using for partial page update
I am seeing the same problem in many parts of our application whenever there is an Ajax command on the page. This is part of a JSF 1.1 to JSF 2.1 migration.
The problem is that whenever an ajax call is made (say on dropdown selection) to update part of the page, the next full submit (usually a Save function linked to a commandButton) just causes a re-write of the page and does not hit the bean method specified on the commandButton's action attribute (server breakpoint never triggered). Hitting the Save button a second time works, but obviously this is not acceptable.
I found that setting execute="@form" and render="@form" on the <f:ajax> setting gets it to work on the first Save button press but we have hundreds of ajax calls in our pages and doing that is not in the spirit of Ajax's "only send and update what you need" philosophy. It would be much nicer to have it work as intended.
Note that in JSF 1.1 we used Richfaces a4j and although we are using the latest (4.3.1) version in it the new project (and it has the same problem), I can easily reproduce the problem using the built-in JSF 2's <f:ajax> so will keep the focus on native MyFaces.
I suspect I have missed something but am at a loss as to what it could be and now also at what to try next. I have traced the http data in both cases and they appear to be the same so the question I have is how to determine why the submit code that just re-writes the screen is deciding to do that instead of calling the bean's save function. Hopefully the hint that it works ok when the ajax execute and render attributes are set to "@form" will help someone quickly identify the problem area or what I can do to identify it.
Here are the details of my environment if it helps.
Web.xml settings:
javax.faces.STATE_SAVING_METHOD = server
org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION = 20
org.apache.myfaces.SERIALIZE_STATE_IN_SESSION = false
org.apache.myfaces.COMPRESS_STATE_IN_SESSION = true
org.apache.myfaces.ALLOW_JAVASCRIPT = true
org.apache.myfaces.DETECT_JAVASCRIPT = false
org.apache.myfaces.PRETTY_HTML = true
org.apache.myfaces.AUTO_SCROLL = false
org.apache.myfaces.CHECK_EXTENSIONS_FILTER = false
javax.faces.VALIDATE_EMPTY_FIELDS = false
javax.faces.PROJECT_STAGE = Development
// played with the following but inconsistent results
javax.faces.PARTIAL_STATE_SAVING = true
org.apache.myfaces.STRICT_JSF_2_REFRESH_TARGET_AJAX = false
org.apache.myfaces.RENDER_VIEWSTATE_ID = true
We also use tomahawk and register the extension filter primarily for the file upload max file size setting.
And we make use of templating to isolate the header, footer, left side menu and right-side main content areas.. The right-side main content area is where a most of the work is done. Here is the start of most page parts for this area:
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:t="http://myfaces.apache.org/tomahawk"
xmlns:a4j="http://richfaces.org/a4j"
xmlns:j4j="http://javascript4jsf.dev.java.net/"
>
<h:body>
<ui:composition>
<h:outputScript library="js" name="manyToMany.js" />
<f:subview id="mappingView" >
<h:form id="mappingForm" >
<t:htmlTag value="center" >
<t:div styleClass='formBorder'>
And here are two examples of command buttons with ajax, first has the problem and the second does not - only difference is the execute and render values on the ajax calls.
<h:commandButton styleClass="manyToManyButton"
value="Add that causes submit to fail - note the execute and render values on ajax call" >
<f:ajax event="click" execute="mappedValuesGrid" render="mappedValuesGrid"
listener="#{myBean.actionAdd}" />
</h:commandButton>
<h:commandButton styleClass="manyToManyButton"
value="Add that works - note the "@form" usage on ajax command >
<f:ajax event="click" execute="@form" render="@form"
listener="#{myBean.actionAdd}" />
</h:commandButton>
Many thanks to anyone who can help.
Jon
RE: Having a problem with MyFaces 2.1.10 (and 2.1.11) commandButton
submit *AFTER* using for partial page update
Posted by Jon Bionda <jb...@csdcsystems.com>.
Problem found. We have a phase listener to detect double clicks and it had code to ignore ajax requests - it needed updating to detect these in JSF 2. Sorry for the noise, but was glad to get the info about issues with multiple forms. We have plans to reduce to a single form defined in the template.
Jon
-----Original Message-----
From: Leonardo Uribe [mailto:lu4242@gmail.com]
Sent: April-01-13 6:01 PM
To: MyFaces Discussion
Subject: Re: Having a problem with MyFaces 2.1.10 (and 2.1.11) commandButton submit *AFTER* using <f:ajax> for partial page update
Hi
2013/4/1 Jon Bionda <jb...@csdcsystems.com>
> I am seeing the same problem in many parts of our application whenever
> there is an Ajax command on the page. This is part of a JSF 1.1 to
> JSF 2.1 migration.
>
> The problem is that whenever an ajax call is made (say on dropdown
> selection) to update part of the page, the next full submit (usually a
> Save function linked to a commandButton) just causes a re-write of the
> page and does not hit the bean method specified on the commandButton's action
> attribute (server breakpoint never triggered). Hitting the Save button a
> second time works, but obviously this is not acceptable.
>
> I found that setting execute="@form" and render="@form" on the
> <f:ajax> setting gets it to work on the first Save button press but we
> have hundreds of ajax calls in our pages and doing that is not in the
> spirit of Ajax's "only send and update what you need" philosophy. It
> would be much nicer to have it work as intended.
>
> Note that in JSF 1.1 we used Richfaces a4j and although we are using
> the latest (4.3.1) version in it the new project (and it has the same
> problem), I can easily reproduce the problem using the built-in JSF
> 2's <f:ajax> so will keep the focus on native MyFaces.
>
> I suspect I have missed something but am at a loss as to what it could
> be and now also at what to try next. I have traced the http data in
> both cases and they appear to be the same so the question I have is
> how to determine why the submit code that just re-writes the screen is
> deciding to do that instead of calling the bean's save function.
> Hopefully the hint that it works ok when the ajax execute and render
> attributes are set to "@form" will help someone quickly identify the
> problem area or what I can do to identify it.
>
> Here are the details of my environment if it helps.
>
> Web.xml settings:
> javax.faces.STATE_SAVING_METHOD = server
> org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION = 20
> org.apache.myfaces.SERIALIZE_STATE_IN_SESSION = false
> org.apache.myfaces.COMPRESS_STATE_IN_SESSION = true
> org.apache.myfaces.ALLOW_JAVASCRIPT = true
> org.apache.myfaces.DETECT_JAVASCRIPT = false
> org.apache.myfaces.PRETTY_HTML = true
> org.apache.myfaces.AUTO_SCROLL = false
> org.apache.myfaces.CHECK_EXTENSIONS_FILTER = false
> javax.faces.VALIDATE_EMPTY_FIELDS = false
> javax.faces.PROJECT_STAGE = Development
>
> // played with the following but inconsistent results
> javax.faces.PARTIAL_STATE_SAVING = true
> org.apache.myfaces.STRICT_JSF_2_REFRESH_TARGET_AJAX = false
> org.apache.myfaces.RENDER_VIEWSTATE_ID = true
>
> We also use tomahawk and register the extension filter primarily for
> the file upload max file size setting.
>
> And we make use of templating to isolate the header, footer, left side
> menu and right-side main content areas.. The right-side main content
> area is where a most of the work is done. Here is the start of most
> page parts for this area:
>
> <!DOCTYPE html>
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:ui="http://java.sun.com/jsf/facelets"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:f="http://java.sun.com/jsf/core"
> xmlns:t="http://myfaces.apache.org/tomahawk"
> xmlns:a4j="http://richfaces.org/a4j"
> xmlns:j4j="http://javascript4jsf.dev.java.net/"
> >
> <h:body>
> <ui:composition>
> <h:outputScript library="js" name="manyToMany.js" />
> <f:subview id="mappingView" >
> <h:form id="mappingForm" >
> <t:htmlTag value="center" >
> <t:div styleClass='formBorder'>
>
>
> And here are two examples of command buttons with ajax, first has the
> problem and the second does not - only difference is the execute and
> render values on the ajax calls.
>
> <h:commandButton styleClass="manyToManyButton"
> value="Add that causes submit to fail - note the
> execute and render values on ajax call" >
> <f:ajax event="click" execute="mappedValuesGrid"
> render="mappedValuesGrid"
> listener="#{myBean.actionAdd}" />
> </h:commandButton>
>
>
> <h:commandButton styleClass="manyToManyButton"
> value="Add that works - note the "@form" usage on ajax
> command >
> <f:ajax event="click" execute="@form" render="@form"
> listener="#{myBean.actionAdd}" />
> </h:commandButton>
>
>
> Many thanks to anyone who can help.
>
>
Try this:
<f:ajax event="click" execute="@this mappedValuesGrid"
render="mappedValuesGrid"
If the button is not executed, the broadcast does not occur and the event is not processed. If the event is not processed, the listener that process the submit will not be executed, and finally you'll see the described behavior.
Another advice is use firebug to check what happen on the first request and the response from the server. In some cases, it could be a hidden ViewExpiredException, but on production case the message is not displayed on the screen.
If that does not work, check if in your page you are using multiple forms, there is a trick for update all form hidden fields at once with myfaces.
http://werpublogs.blogspot.com/2011/11/jsf-ajax-and-multiple-forms.html
If any of that does work, let us know. I don't think there is a problem in Myfaces code, this part has been widely tested, but maybe there is something very specific in your pages.
regards,
Leonardo Uribe
> Jon
>
>
>
RE: Having a problem with MyFaces 2.1.10 (and 2.1.11) commandButton
submit *AFTER* using for partial page update
Posted by Jon Bionda <jb...@csdcsystems.com>.
Thanks Leonardo, it is very likely the multiple form issue as our template structure pulls in separate page pieces and I know there are at least 2 forms in the final output. I will dig into it tomorrow and let the list know how it turns out.
Jon
-----Original Message-----
From: Leonardo Uribe [mailto:lu4242@gmail.com]
Sent: April-01-13 6:01 PM
To: MyFaces Discussion
Subject: Re: Having a problem with MyFaces 2.1.10 (and 2.1.11) commandButton submit *AFTER* using <f:ajax> for partial page update
Hi
2013/4/1 Jon Bionda <jb...@csdcsystems.com>
> I am seeing the same problem in many parts of our application whenever
> there is an Ajax command on the page. This is part of a JSF 1.1 to
> JSF 2.1 migration.
>
> The problem is that whenever an ajax call is made (say on dropdown
> selection) to update part of the page, the next full submit (usually a
> Save function linked to a commandButton) just causes a re-write of the
> page and does not hit the bean method specified on the commandButton's action
> attribute (server breakpoint never triggered). Hitting the Save button a
> second time works, but obviously this is not acceptable.
>
> I found that setting execute="@form" and render="@form" on the
> <f:ajax> setting gets it to work on the first Save button press but we
> have hundreds of ajax calls in our pages and doing that is not in the
> spirit of Ajax's "only send and update what you need" philosophy. It
> would be much nicer to have it work as intended.
>
> Note that in JSF 1.1 we used Richfaces a4j and although we are using
> the latest (4.3.1) version in it the new project (and it has the same
> problem), I can easily reproduce the problem using the built-in JSF
> 2's <f:ajax> so will keep the focus on native MyFaces.
>
> I suspect I have missed something but am at a loss as to what it could
> be and now also at what to try next. I have traced the http data in
> both cases and they appear to be the same so the question I have is
> how to determine why the submit code that just re-writes the screen is
> deciding to do that instead of calling the bean's save function.
> Hopefully the hint that it works ok when the ajax execute and render
> attributes are set to "@form" will help someone quickly identify the
> problem area or what I can do to identify it.
>
> Here are the details of my environment if it helps.
>
> Web.xml settings:
> javax.faces.STATE_SAVING_METHOD = server
> org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION = 20
> org.apache.myfaces.SERIALIZE_STATE_IN_SESSION = false
> org.apache.myfaces.COMPRESS_STATE_IN_SESSION = true
> org.apache.myfaces.ALLOW_JAVASCRIPT = true
> org.apache.myfaces.DETECT_JAVASCRIPT = false
> org.apache.myfaces.PRETTY_HTML = true
> org.apache.myfaces.AUTO_SCROLL = false
> org.apache.myfaces.CHECK_EXTENSIONS_FILTER = false
> javax.faces.VALIDATE_EMPTY_FIELDS = false
> javax.faces.PROJECT_STAGE = Development
>
> // played with the following but inconsistent results
> javax.faces.PARTIAL_STATE_SAVING = true
> org.apache.myfaces.STRICT_JSF_2_REFRESH_TARGET_AJAX = false
> org.apache.myfaces.RENDER_VIEWSTATE_ID = true
>
> We also use tomahawk and register the extension filter primarily for
> the file upload max file size setting.
>
> And we make use of templating to isolate the header, footer, left side
> menu and right-side main content areas.. The right-side main content
> area is where a most of the work is done. Here is the start of most
> page parts for this area:
>
> <!DOCTYPE html>
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:ui="http://java.sun.com/jsf/facelets"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:f="http://java.sun.com/jsf/core"
> xmlns:t="http://myfaces.apache.org/tomahawk"
> xmlns:a4j="http://richfaces.org/a4j"
> xmlns:j4j="http://javascript4jsf.dev.java.net/"
> >
> <h:body>
> <ui:composition>
> <h:outputScript library="js" name="manyToMany.js" />
> <f:subview id="mappingView" >
> <h:form id="mappingForm" >
> <t:htmlTag value="center" >
> <t:div styleClass='formBorder'>
>
>
> And here are two examples of command buttons with ajax, first has the
> problem and the second does not - only difference is the execute and
> render values on the ajax calls.
>
> <h:commandButton styleClass="manyToManyButton"
> value="Add that causes submit to fail - note the
> execute and render values on ajax call" >
> <f:ajax event="click" execute="mappedValuesGrid"
> render="mappedValuesGrid"
> listener="#{myBean.actionAdd}" />
> </h:commandButton>
>
>
> <h:commandButton styleClass="manyToManyButton"
> value="Add that works - note the "@form" usage on ajax
> command >
> <f:ajax event="click" execute="@form" render="@form"
> listener="#{myBean.actionAdd}" />
> </h:commandButton>
>
>
> Many thanks to anyone who can help.
>
>
Try this:
<f:ajax event="click" execute="@this mappedValuesGrid"
render="mappedValuesGrid"
If the button is not executed, the broadcast does not occur and the event is not processed. If the event is not processed, the listener that process the submit will not be executed, and finally you'll see the described behavior.
Another advice is use firebug to check what happen on the first request and the response from the server. In some cases, it could be a hidden ViewExpiredException, but on production case the message is not displayed on the screen.
If that does not work, check if in your page you are using multiple forms, there is a trick for update all form hidden fields at once with myfaces.
http://werpublogs.blogspot.com/2011/11/jsf-ajax-and-multiple-forms.html
If any of that does work, let us know. I don't think there is a problem in Myfaces code, this part has been widely tested, but maybe there is something very specific in your pages.
regards,
Leonardo Uribe
> Jon
>
>
>
Re: Having a problem with MyFaces 2.1.10 (and 2.1.11) commandButton
submit *AFTER* using for partial page update
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
2013/4/1 Jon Bionda <jb...@csdcsystems.com>
> I am seeing the same problem in many parts of our application whenever
> there is an Ajax command on the page. This is part of a JSF 1.1 to JSF 2.1
> migration.
>
> The problem is that whenever an ajax call is made (say on dropdown
> selection) to update part of the page, the next full submit (usually a Save
> function linked to a commandButton) just causes a re-write of the page and
> does not hit the bean method specified on the commandButton's action
> attribute (server breakpoint never triggered). Hitting the Save button a
> second time works, but obviously this is not acceptable.
>
> I found that setting execute="@form" and render="@form" on the <f:ajax>
> setting gets it to work on the first Save button press but we have hundreds
> of ajax calls in our pages and doing that is not in the spirit of Ajax's
> "only send and update what you need" philosophy. It would be much nicer
> to have it work as intended.
>
> Note that in JSF 1.1 we used Richfaces a4j and although we are using the
> latest (4.3.1) version in it the new project (and it has the same problem),
> I can easily reproduce the problem using the built-in JSF 2's <f:ajax> so
> will keep the focus on native MyFaces.
>
> I suspect I have missed something but am at a loss as to what it could be
> and now also at what to try next. I have traced the http data in both
> cases and they appear to be the same so the question I have is how to
> determine why the submit code that just re-writes the screen is deciding to
> do that instead of calling the bean's save function. Hopefully the hint
> that it works ok when the ajax execute and render attributes are set to
> "@form" will help someone quickly identify the problem area or what I can
> do to identify it.
>
> Here are the details of my environment if it helps.
>
> Web.xml settings:
> javax.faces.STATE_SAVING_METHOD = server
> org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION = 20
> org.apache.myfaces.SERIALIZE_STATE_IN_SESSION = false
> org.apache.myfaces.COMPRESS_STATE_IN_SESSION = true
> org.apache.myfaces.ALLOW_JAVASCRIPT = true
> org.apache.myfaces.DETECT_JAVASCRIPT = false
> org.apache.myfaces.PRETTY_HTML = true
> org.apache.myfaces.AUTO_SCROLL = false
> org.apache.myfaces.CHECK_EXTENSIONS_FILTER = false
> javax.faces.VALIDATE_EMPTY_FIELDS = false
> javax.faces.PROJECT_STAGE = Development
>
> // played with the following but inconsistent results
> javax.faces.PARTIAL_STATE_SAVING = true
> org.apache.myfaces.STRICT_JSF_2_REFRESH_TARGET_AJAX = false
> org.apache.myfaces.RENDER_VIEWSTATE_ID = true
>
> We also use tomahawk and register the extension filter primarily for the
> file upload max file size setting.
>
> And we make use of templating to isolate the header, footer, left side
> menu and right-side main content areas.. The right-side main content area
> is where a most of the work is done. Here is the start of most page parts
> for this area:
>
> <!DOCTYPE html>
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:ui="http://java.sun.com/jsf/facelets"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:f="http://java.sun.com/jsf/core"
> xmlns:t="http://myfaces.apache.org/tomahawk"
> xmlns:a4j="http://richfaces.org/a4j"
> xmlns:j4j="http://javascript4jsf.dev.java.net/"
> >
> <h:body>
> <ui:composition>
> <h:outputScript library="js" name="manyToMany.js" />
> <f:subview id="mappingView" >
> <h:form id="mappingForm" >
> <t:htmlTag value="center" >
> <t:div styleClass='formBorder'>
>
>
> And here are two examples of command buttons with ajax, first has the
> problem and the second does not - only difference is the execute and render
> values on the ajax calls.
>
> <h:commandButton styleClass="manyToManyButton"
> value="Add that causes submit to fail - note the execute
> and render values on ajax call" >
> <f:ajax event="click" execute="mappedValuesGrid"
> render="mappedValuesGrid"
> listener="#{myBean.actionAdd}" />
> </h:commandButton>
>
>
> <h:commandButton styleClass="manyToManyButton"
> value="Add that works - note the "@form" usage on ajax
> command >
> <f:ajax event="click" execute="@form" render="@form"
> listener="#{myBean.actionAdd}" />
> </h:commandButton>
>
>
> Many thanks to anyone who can help.
>
>
Try this:
<f:ajax event="click" execute="@this mappedValuesGrid"
render="mappedValuesGrid"
If the button is not executed, the broadcast does not occur and the event
is not processed. If the event is not processed, the listener that process
the submit will not be executed, and finally you'll see the described
behavior.
Another advice is use firebug to check what happen on the first request and
the response from the server. In some cases, it could be a hidden
ViewExpiredException, but on production case the message is not displayed
on the screen.
If that does not work, check if in your page you are using multiple forms,
there is a trick for update all form hidden fields at once with myfaces.
http://werpublogs.blogspot.com/2011/11/jsf-ajax-and-multiple-forms.html
If any of that does work, let us know. I don't think there is a problem in
Myfaces code, this part has been widely tested, but maybe there is
something very specific in your pages.
regards,
Leonardo Uribe
> Jon
>
>
>