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
