myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Bionda <>
Subject RE: Having a problem with MyFaces 2.1.10 (and 2.1.11) commandButton submit *AFTER* using <f:ajax> for partial page update
Date Tue, 02 Apr 2013 17:21:52 GMT
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.


-----Original Message-----
From: Leonardo Uribe [] 
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


2013/4/1 Jon Bionda <>

> 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=""
>       xmlns:ui=""
>       xmlns:h=""
>       xmlns:f=""
>       xmlns:t=""
>       xmlns:a4j=""
>       xmlns:j4j=""
>       >
> <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"

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.

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.


Leonardo Uribe

> Jon

View raw message