Java Mailing List Archive

http://www.junlu.com/

Home » users.myfaces »

Having a problem with MyFaces 2.1.10 (and 2.1.11) commandButton
submit *AFTER* using <f:ajax> for partial page update

Jon Bionda

2013-04-01

Replies: Find Java Web Hosting

Author LoginPost Reply
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="@(protected).

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 "@(protected).

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 "@(protected) >
   <f:ajax event="click" execute="@(protected)"
        listener="#{myBean.actionAdd}" />
 </h:commandButton>


Many thanks to anyone who can help.

Jon


©2008 junlu.com - Jax Systems, LLC, U.S.A.