• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Clearing a page

 
Ranch Hand
Posts: 159
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am having trouble clearing a form using "Reset", and would most appreciate some help.

Bassically I have the index page, and options 1, 2 and 3. I will have the beans MyOption1Bean, MyOption2Bean and MyOption3bean for the three option pages, respectively, that will contain only getters and setters specific to those options. In addtion, I will have the bean, MyOptionBean (no number) that will have getters and setters for the index page, getters and setters that are common to more than one of the option pages, and actions and file I/O etc.

The page option1.xhtml has a reset button as follows:

which is supposed to reset the form, and is where I'm having the trouble.

It is linked to an action in MyOptionBean at the end of the listing here:

where I'm accessing the values in MyOption1Bean, and eventually the other two.

The contents of MyOption1Bean are just getters and setters, such as here:

The problem I have is when the form in option1.xhtml is first filled in, if the reset button is clicked without submitting the values, the form is cleared, as it should be, regardless of whether I have it is linked to any actions. However, if I enter values in the form, submit them, then return back to the same form using the JSF navigation, not using the browser buttons, the contents of the form are still displayed. That in itself is not necessarily a problem as one may want to change a couple of the values and resubmit the form. The problem is that the reset does not work, using either of the two methods in the action in the listing above, one of which is commented out, or trying something very simple, such as:

where I have just called up the methods in myOption1Bean to set the values back to empty.

None of these work. To summarize, values are cleared in the form when the "Reset" button is clicked, but only if the values have not been submitted, otherwise they will not clear. I suspect that on clicking "Reset" the values are cleared in the bean, but the bean then picks up the values still held in the option1.xhtml page.

The only way I can solve this is by using JavaScript to clear the fields of the HTML form. Is there a way of directly crearing the values in the bean? I would very much appreciate some help on this.

Incidentally, although createValueBinding() is depricated, I still tried it out. If this problem can be solved, I would obviously not want to use depricated methods.
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm afraid you've provided more information than I can conveniently read so I'll do what I do in such cases and tell you what should be happening.

Item: The commandButton "type="reset"" should be generating an HTML INPUT TYPE=RESET control. This control works entirely locally to the browser. It restores all of the controls on the form that contains it to the values they had when the view was loaded. It does this without using JavaScript or server request/response. I'm not sure - the Sun documentation on this is pretty horrible - but I wouldn't expect a type=reset command button to fire the action method. If it did, the action would probably be contingent on whether the form data was valid. Which could be confusing, since the RESET operation should not be.

Item: When you navigate to a view, the control values on that view will be set based on the current backing bean property values. So if the values you see on the display aren't what you expected, check the backing bean.
 
Christopher Sharp
Ranch Hand
Posts: 159
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry for making this rather long and rambling. I had forgotten that if the button is set to type="reset" it doesn't fire an action on the server, but not specifying it has being type="reset" although still labeling it as a reset button and putting in an action does not help either.

Basically, if you start with values from a bean that are empty, such as when the page is first visited, populate the form without clicking "Submit" but instead click "Reset", the form is cleared. as it should be. If the form is populated then the "Submit" button is clicked, the beans are given values, as they should, then you navaigate to another page specified by the action. However, if you go back to the form a second time, the original values are still there because they are picked up from the bean when the page is reloaded. That is not necessarily a problem. However, in that case "Reset" does not clear the form, and instead sets the values back to the previous values if you change some of the contents of the form then click "Reset". How do you get "Reset" to work if the bean has values, that is my main question?

However, on clicking "Submit" with the form populated and having the action clear the values of the bean, then when you navigate back to the page the form is indeed cleared, but how do you clear a form without having to go to another page?

Incidentally, all my beans are Session scoped.
 
Tim Holloway
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"Empty" is a misleading term. JSF will always render a View using the current property values of that bean. Whatever they may be. If you didn't include explicit constructor/instance initialization code then initially numeric primitive properties will be set to zero, binary primitive properties will be set to false, Strings will be set to null, as will all other class objects. When such a bean is rendered, the null strings will render as empty strings (since HTML doesn't support nulls), and class objects will simply offend it, because they're not terminal properties. Accessing a terminal property of an unconstructed class results in a NullPointerException.

An HTML RESET control will, as I said, revert to the values that were downloaded to the client when the current instance of the View was rendered. If you SUBMIT the form and it doesn't navigate to a new page, that means that the current page is re-rendered and the new revert values will be whatever they were at the end of the action processing for the SUBMIT - not the values that they were on the original display. If you do an AJAX submit, the results are more complex, because they depend on what parts of the form were re-rendered as part of the AJAX response processing.

If the user navigates via the browser BACK button, all bets are off. If the browser decides to simply yank the page out of local cache, then the RESET values will be whatever they were when the page was originally rendered. However, if the BACK button resubmits the form, then a new page will be rendered based on the backing bean's current values.

The BACK button is a right royal pain, just as it has always been JSF2 attempted to mitigate some of its tricks, but ultimately you are at the mercy (if any) of the user's client software (browser).

When I have a bean in session scope and I want to re-initialize it for later re-use, I create an internal init() method. This method is called by both the constructor and by whatever utility method(s) I may provide for the use of an action(s) process(es) that navigates to a View which references that bean. For CRUD beans, that utility method is often named beginAdd().
 
Greenhorn
Posts: 23
Eclipse IDE Tomcat Server Debian
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I just finished a page that implements editing data and inserting data using the same <h:form> and the same backing bean. I did use the "RESET" combined with an action="#{MyClass.resetData}" where I nulled out each of the field values. This seems to work fine, a little tedious, if the form is populated with much data, but so far effective. I'll keep this topic in my watches, to see if there is a trick, but it sounds like after the form is populated and a Request has been sent, and the backing bean updated, the "memory" of the browser will always return what was last sent.
 
Tim Holloway
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Every HTTP client/server interaction consists of 2 parts: Request and Response in strict 1-to-1 correspondence. This is true whether it's JSF or not and in fact, even whether it's java or not. That's a core part of the HTTP protocol RFC specification.

When you submit a form to a server (Request), the server will return a page (Response). As far as the client is concerned, it doesn't matter whether or not it's actually a different page or not visually or architecturally. All that matters is that it's the result of a different Request. And the values that came back in that response are what an HTML RESET button will use to reset the form that contains it. Previous responses are of no account, whether identical or not. Again, this isn't a JSF thing, it's basic HTML/HTTP. The client doesn't understand JSF, so everything on the client side gets converted to/from HTML by the server.

AJAX can complicate matters, since only part of a page is sent and only part of a page is returned, but the same rules apply.
 
Christopher Sharp
Ranch Hand
Posts: 159
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
OK, many thanks, I think that has cleared that up, more or less, and I have found a way of dealing with this issue.
reply
    Bookmark Topic Watch Topic
  • New Topic