0

I think i came across a bug of @ViewScoped with a4j:commandButton.

I have a very complex form where all actions use a4j, except those that need to upload data. And depending on the order of the commands the validation of the viewParam breaks.

Here is the working code:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core"
      xmlns:a4j="http://richfaces.org/a4j" >

  <f:metadata>
    <f:viewParam id="viewParam" name="viewParam" value="#{bean.viewParam}" required="true" />
  </f:metadata>
  <h:head>
    <title>Test View Param</title>
  </h:head>
  <h:body>
    <h:message for="viewParam" />
    <hr/>
    <h:form>
      #{bean.viewParam}<br/>
      <h:commandButton value="cmdButton" />
      <a4j:commandButton value="a4jBtn" execute="@this" render="@form" />
    </h:form>  
  </h:body>
</html>

just click on the a4jBtn and then on the cmdButton to see the problem. you will see that the parameter is still there! but that the validation fails.

<t:saveState> does not help, <rich:message> is also not better, but

<h:commandButton value="ajaxBtn" ><f:ajax execute="@this" render="@form" /></h:commandButton>

instead of

<a4j:commandButton value="a4jBtn" execute="@this" render="@form" />

does work correctly!

Using myFaces 2.0.15 and richFaces 4.2.3.Final on Tomcat 6.0.18 and jboss-el 2.0.0.GA.

i could workaround my problem by using f:ajax instead of a4j:commandButton, but maybe you have a better idea, or you could just explain to me what is going wrong?

mmoossen
  • 1,135
  • 3
  • 19
  • 28
  • fixed by using omnifaces and . Big thanks to @BalusC. – mmoossen Jan 07 '13 at 15:54
  • You're welcome. I already saw this question and already knew that `` would do it. I'm not sure why I didn't bother to answer it. Perhaps because I didn't want to push "again another library" through the throat :) It may be helpful if you mention in future questions that you're using OmniFaces as well. – BalusC Jan 07 '13 at 15:57
  • @BalusC: ok, right. i will do mention OmniFaces in the future. but now write an answer, please! – mmoossen Jan 08 '13 at 09:16
  • @BalusC: i had even more Issues with `@ViewScoped`, but everything works now just by using ``, it is a shame that this is not addressed in the core. Btw, my reason to start using OmniFaces was http://stackoverflow.com/questions/10449862/what-is-the-correct-way-to-deal-with-jsf-2-0-exceptions-for-ajaxified-components. – mmoossen Jan 08 '13 at 09:39
  • You might want to take time to wade through the showcase examples to learn what OmniFaces all provides: https://showcase-omnifaces.rhcloud.com/ More than often, it just solves some shortcomings in JSF. – BalusC Jan 08 '13 at 14:36

1 Answers1

1

You basically need to retain the view parameters on synchronous postbacks. As you're using OmniFaces, you could use <o:form> for that.

<o:form includeViewParams="true">

Or as you're already using a view scoped bean, trigger the validation only on non-postbacks.

<f:viewParam ... required="#{not facesContext.postback}" />

Or, as you're using OmniFaces, you could use <o:viewParam> instead which skips the validation/conversion/update on postbacks.

<o:viewParam ... />
Community
  • 1
  • 1
BalusC
  • 992,635
  • 352
  • 3,478
  • 3,452