2

I've got the following button:

<a4j:commandButton value="#{AppMessages['general.action.cancel']}"
            disabled="#{!entityBB.expandState.editable}"
            actionListener="#{entityBB.cancel}"
            render="initialServicePanel :messages" status="ajaxStatus"
            immediate="true" />

In my case the above button does everything I need (remove the inError state from an uiComponent to rerender it and reset (cancel) everything in the form to its previous state).

When I try to use it as this:

<h:commandButton value="#{AppMessages['general.action.cancel']}"
    disabled="#{!entityBB.expandState.editable}" immediate="true">
        <a4j:ajax execute="@this" render="initialServicePanel :messages"
        listener="#{entityBB.cancel}" status="ajaxStatus" />
</h:commandButton>

it isn't working (the value gets reset but the uiComponent (an inputText) stays red though in error). Why is this? I can't figure out the difference between the two of them since I thought an a4j:commandButton was just an h:commandButton with a4j:ajax in it behind the scenes.

EDIT: Now I've got another situation where the h:commandButton removes the value but keeps it in error (red border). And the a4j:commandButton removes it from in error (red border) but keeps the value.. It's the exact same input as above. I can't explain it.. Anyone?

GregD
  • 1,884
  • 2
  • 28
  • 55
  • Which JSF impl/version and which RichFaces version? – BalusC Aug 01 '14 at 17:29
  • @BalusC We are using JEE5 so JSF 1.2 and RichFaces 4.2.2.Final. – GregD Aug 04 '14 at 08:05
  • "JSF 1.2" is a spec version. I asked for impl and its version. E.g. "Mojarra 1.2_15" or "MyFaces 1.2.12". This information is visible in server log. By the way, how exactly did you manage to run RichFaces 4.x on JSF 1.2? That RichFaces version is designed for JSF 2.0. You'd better verify once more if you're really using JSF 1.2. – BalusC Aug 04 '14 at 08:08
  • Looked again and the pom said, as variable: `3.9`. The version for richfaces came up in my eclipse while hovering over the dependency. Also noticed the following: ` 3.0 2.0 ` (I did not create the different poms. Sorry for the confusion..) – GregD Aug 04 '14 at 08:20
  • 1
    This is not helpful either. Ask the project owner/lead if you can't figure on your own by just looking at webapp startup log in server log. The last part is by the way coming from Eclipse specific settings file which basically says that project facets are set to Servlet 3.0 and JSF 2.0. But this is only a development time aid and doesn't say anything about the **actually** running JSF impl/version. – BalusC Aug 04 '14 at 08:21
  • My guess is that this is what you are looking for: ` ` – GregD Aug 04 '14 at 08:26
  • This is not coming from the JSF implementation itself. For Mojarra 2.2.7 it looks like this: `INFO: Initializing Mojarra 2.2.7 ( 20140610-1547 https://svn.java.net/svn/mojarra~svn/tags/2.2.7@13362) for context '/playground'` The implementation name "Mojarra" is usually specified in the line. The same applies to the only other JSF implementation "MyFaces". – BalusC Aug 04 '14 at 08:31
  • The possible problem is that we are also relying on a jsf implementation coming from the company we are currently working for. There it says "JSF 3.xxx" and I'm just 100% sure it can't be that. How should it look like? (it's a startup from 1000+ lines and actually never really looked at it in detail until now). Thanks for the help btw.. (and the example) – GregD Aug 04 '14 at 08:32
  • `INFO: Initializing Mojarra (1.2_15-20100923-SNAPSHOT) for context '/Regondes2'` that's it I hope? – GregD Aug 04 '14 at 08:36
  • Yes, that's Mojarra 1.2_15. Thank you. Is the project using `.jsp` or `.xhtml` (Facelets) files? Still wondering as to RichFaces 4.x which is designed for JSF 2.0 only. That'll perhaps explain the some "custom stuff" around your project. One more way to confirm JSF impl/version is printing/debugging the following in `@PostConstruct` of an arbitrary bean: http://stackoverflow.com/questions/13125782/how-to-detect-current-jsf-version/13125869#13125869 – BalusC Aug 04 '14 at 08:37
  • W're using `.xhtml` files. Looking a bit more in the log: `INFO: RichFaces Core Implementation by JBoss by Red Hat, version v.4.2.2.Final` – GregD Aug 04 '14 at 08:39
  • The code check gives me: `version: 1.0.0.0_2-0 vendor: BEA Systems, JavaServer Faces API 1.0` – GregD Aug 04 '14 at 08:45
  • It looks now too much like your webapp is (unnecessarily) embedding a JSF 1.2 library, but that the runtime is *actually* using the WebLogic server bundled JSF 2.0. Can you try once again, but now with `FacesContext.class.getPackage().getSpecificationVersion()` call? Are you indeed deploying to a WebLogic 12.x server? – BalusC Aug 04 '14 at 09:16
  • Kind of unexpected actually (even my project lead got that wrong since he said we were using JSF 1.2 some days ago); `getSpecificationVersion()` returns: `2.0` – GregD Aug 04 '14 at 09:18
  • Okay, that confirms that the webapp is during runtime *actually* using WebLogic 12.x bundled JSF 2.0 which got classloading precedence over the ones bundled in the webapp. I bet you can safely remove/set-to-probvided JSF 1.2 in webapp's pom and still get it to deploy and work the same way. – BalusC Aug 04 '14 at 09:19
  • I will tell my technical projectlead when he gets back on vacation to try it out. My guess actually is it wil keep on working indeed after this explanation. But that doesn't solve my current problem though ^^. – GregD Aug 04 '14 at 09:21
  • Will look at it if the time allows me :) At least versions are finally clear so that I (or anyone else) can actually start trying to reproduce this problem. One more thing please, which WebLogic version exactly? – BalusC Aug 04 '14 at 09:27
  • Thanks in advance! `WebLogic Server Version: 10.3.5.0` – GregD Aug 04 '14 at 09:28

2 Answers2

3

The execute of <a4j:commandButton> defaults to @form, but the one of <a4j:ajax> defaults to @this, which means that only the "current component" is being executed (thus, the button itself). This caused that UIInput#decode() of input components aren't being called during apply request values phase. It's exactly that method which resets the validity back to true.

To achieve exactly the same effect with <h:commandButton><a4j:ajax>, you need to explicitly set the execute attribute of <a4j:ajax> to @form as well.

<h:commandButton ... value="Cancel" immediate="true">
    <a4j:ajax execute="@form" ... />
</h:commandButton>

Update: to clear out the field, which was your initial problem and which actually wouldn't have worked on <a4j:commandButton> either (so the "does everything I need" part is wrong), head to this answer for a breakdown of the problem and both a JSF 2.x and JSF 1.x targeted solution: Input fields hold previous values only if validation failed.

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • You are correct on the part that the execute should be placed inside the `a4j:ajax` to make the `` have the same effect. But my problem is still there. If I use the ` – GregD Aug 06 '14 at 08:29
  • Edit previous comment (can't anymore): The value in my inputField should NOT stay there. Note that both `` and `` (they are in the same form and there is actually nothing different in my eyes). It makes me guess that the inputFields aren't rerenderd or something but then again they are since the inError is removed. – GregD Aug 06 '14 at 08:32
  • `` doesn't clear the field either. There's no difference in this regard. Or is your concrete question actually "How to clear a previously invalidated input field?" and were you just investigating a solution with `` until you wondered about the difference in attempts? Thus your concrete question is *not* "What's the difference between `` and ``?" ? So you essentially have a XY-problem? – BalusC Aug 06 '14 at 08:48
  • In any case ... This Q&A should do it: http://stackoverflow.com/questions/14371723/input-fields-hold-previous-values-only-if-validation-failed – BalusC Aug 06 '14 at 08:52
  • That's true indeed and I was indeed wondering about the difference between the two and you actually solved that :)! Kind off forgot the initial question title ^^.. The above linked Q&A solves that resetting problem indeed. – GregD Aug 06 '14 at 08:55
  • One more thing (if it's complicated I'll open a new question): Why aren't my fields reset? I'm going to my backingBean, i'm resetting the value of the current entity (used in the view) and then I'm rerendering the view. Shouldn't my values get updated then? – GregD Aug 06 '14 at 09:05
  • 1
    It's explained in the 1st link of the linked answer. – BalusC Aug 06 '14 at 09:19
0

It is not the same code. The translation should be:

<h:commandButton value="#{AppMessages['general.action.cancel']}"
    disabled="#{!entityBB.expandState.editable}" immediate="true"
    actionListener="#{entityBB.cancel}" >
        <a4j:ajax render="initialServicePanel :messages"
        status="ajaxStatus" />
</h:commandButton>

Main differences:

  • Listener is in <h:commandButton>, not in <a4j:ajax>.
  • Removed execute="@this" which will change the data sent to the server.
Luiggi Mendoza
  • 85,076
  • 16
  • 154
  • 332