myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <lu4...@gmail.com>
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 Mon, 01 Apr 2013 22:00:57 GMT
Hi

2013/4/1 Jon Bionda <jbionda@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
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message