0

I'm trying to implement a cancel button to clear the fields from my entity. Though, when I'm setting the entity to null my fields still keep their value.

Code:

The EntityBB's cancel method (note that the debugger can reach the cancel method):

public void cancelAddStandardLetter() {
    setEntity(null);
    standardLetterInit();
}

this method really sets all the values from the entity back to null and the standardLetterInit method sets some default values that are needed (tried the same method without the standardLetterInit -> same result).

The xhtml page (other inputfields are left out):

<o:form includeRequestParams="true" id="addStandardLetterForm">

    <h:inputTextvalue="#{entityBB.entity.fileName}" styleClass="rInput"/>

    <h:commandButton value="Cancel" immediate="true"
            styleClass="floatRight"
            action="#{entityBB.cancelAddStandardLetter()}" />
</o:form>

After pressing the "cancel" button, the values being typed in the "fileName" field are still there. How can that be?

GregD
  • 1,884
  • 2
  • 28
  • 55
  • sounds like you want [o:ignoreValidationFailed](http://showcase.omnifaces.org/taghandlers/ignoreValidationFailed) instead of `immediate="true"` (or simply reload the page and initialize in a `@PostConstruct` method)? – mabi Jan 27 '14 at 14:09
  • The logic behind it is more complex then this small setup but the basics are the same. I need to use immediate="true" because there is also a save button etc in it. So I can't but my complete form on ignoreValidation. PostConstruct also can't be used because my entity will already exist before I'm entering this screen. (Bean is viewscoped and this input fields are rendered by a button click.) – GregD Jan 27 '14 at 15:45
  • I don't get it. You have a complex form and some fields can be reset by clicking a "Cancel" button. Why do you need to have `immediate` here? The way I've done that is having a `` on the button together with a ``. – mabi Jan 27 '14 at 16:47
  • 2
    Should that *Cancel* button be renamed to *Clear* or *Reset* maybe? Let's keep concepts clear. – Aritz Jan 27 '14 at 17:26
  • Xtreme Biker, I can't change what the business asks. If they want to name it cancel then I have to name it cancel. Mabi, I thought I would need the immediate true to skip the validation step in the lifecycle. But BalusC's answer seems good and I'm going to try that one out! – GregD Jan 28 '14 at 08:50
  • 1
    Well, that's one of the things `immediate` does. My point from above was that `o:ignoreValidationFailed` applied to your `h:commandButton` does *only* that, without all the nasty suprises executing your business logic in the Apply Request Values phase brings. – mabi Jan 29 '14 at 07:58

1 Answers1

1

Make sure that the bean is view scoped and use a plain GET button.

<h:button value="Cancel" />

This basically refreshes the page. It'll recreate the view scoped bean instance. No need to submit the whole form. If the input values still appear, then it's either the browser cache or autocomplete/autofill which you in turn can control with respectively a servlet filter and autocomplete="off".

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • If I do this, then I'm losing other values in my backingBean that I need to keep. So this doesn't seem an option either. But I'm going to refactor the whole setup to make it easier to maintain the application and that will probably also fix my problem. – GregD Jan 28 '14 at 09:27