Verified ICEfaces 4 trunk r47630. Tomcat 8, FF 43, Chrome 47, IE 11, 10, 9, 8.
QA Test applications have been modified as required.

r47580: updated flipswitch reset script to use new function to check for existence of reset value

I reviewed the mobi components, and they are working fine, or as expected.

As for mobi:flipswitch, it's easier to see the reset functionality if you preload the component with the value 'true'. So that pressing the reset button will set it to true again, and pressing the clear button will set it to false.

As for mobi:dateSpinner and mobi:timeSpinner, I also recommend to preload a value (a specific date or time, which is not right now) in order to see the reset functionality more clearly, otherwise pressing the reset button will simply clear the field instead of displaying the original date or time.

As for mobi:geolocation, it seems the reset functionality won't be applicable, because of the nature of the component. This component can't be preloaded with a value. It's only used to fetch the location of the device, so it doesn't make sense to preload it with a specific value, and the code doesn't permit this anyway. So, the only thing you'll see is that the hidden field will be set to the empty string when pressing the reset button (after you pressed the locate me button).

r47572: fixed issues with inField labels in ace:autoCompleteEntry, ace:textEntry, ace:textAreaEntry, and ace:maskedEntry; fixed issues in ace:comboBox and ace:selectMenu with not restoring the inField label when resetting if the original value was empty; implemented reset functionality in ace:simpleSelectOneMenu since the new reset value was constantly being updated after each form submission; modified the general strategy for reset values to check if a value is set instead of if it's empty

This commit fixes the issues with ACE components reported above and some other issues. The other issues noticed were that ace:comboBox and ace:selectMenu, when having an inField label and an empty initial value, were clearing the text field when pressing the reset button, instead of restoring the inField label in the field. Also, ace:simpleSelectOneMenu was previously relying on the native reset() function, but this didn't provide the desired "revert" behaviour; if the value of this component was updated after a form request, this new value became the new reset value, instead of it being the very first value with which the page was loaded.

Because of these issues, I would advise to test components that support inField labels with and without preloaded values.

As for the behaviour with standard JSF components. They simply won't have the revert behaviour that ACE components have, since they rely on the native reset() function, which simply resets to whatever value was in the markup before the user interacted with the input element. So, if a dynamic update changes the value of a standard JSF component, this new value will become the new reset value, because the markup has changed.

Tested with ICEfaces 4 trunk r47059.
Testing shows that after pressing the reset button an infield label can become a value that can be submitted. This issue is seen in the ace:textEntry, ace:autoCompleteEntry, ace:maskedEntry and ace:textAreaEntry components in Form 1.
Test application ICE-10899.jsf located at:
http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/pushButton
http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/linkButton

To reproduce:
1.) Load test application and navigate to ICE-10899 - ace:pushButton Reset Attribute.
2.) Note that the ace:textEntry has an inField label. Input a few characters into the ace:textEntry
3.) Use the Reset button near the bottom of the form.
4.) Note that the input is reset to the inField label, but the label is no longer ghosted and appears as regular text.
5.) If you press the submit button the label will be submitted as a value.

An issue was noticed with ace:maskedEntry when using the reset button then the clear button. By doing so, new text entered into the ace:maskedEntry appears as though it is an inField label and the value can not be submitted.
To reproduce:
1.) Use /ICE-10899.jsf from either the ace:pushButton or ace:linkButton QA test apps.
2.) Enter some digits into the ace:maskedEntry in Form 1. Press the Reset Button. The inField label is returned to the ace:maskedEntry although is is not correctly styled as per the issue above.
3.) Press the Clear Button. The inField label now looks as it should.
4.) Enter digits into the ace:maskedEntry. Note these digits appear as though they are an inField label.
5.) Press Submit. The input from the maskedEntry is not sent to the server.

I am not sure how well jsf input components are expected to work with the clear and reset functions. Here are my findings.
Using type=reset in an ace:pushButton or ace:linkButton in a form that contains jsf input components has varied results.
When an f:ajax tag is used with the jsf components the test passes.
When f:ajax is not used some of the sampled jsf input components do not cooperate with the Reset Button. In the QA test example there is an h:inputText, h:inputTextEntry and a h:selectOneMenu in a form. When using the Reset button, only the h:inputText is reset if the reset button is used after a submit. If Reset is pressed before the submit button, then the reset is performed in all the jsf components. This issue applies whether the submit button is in the form of an h:commandButton, or ace:push/LinkButton.

This can be demonstrated with Form 6 in the /ICE-10899.jsf application.
1.) Go to Form 6 in the /ICE-10899.jsf test application.
2.) Add input into each of the fields
3.) Press submit, the values will be updated.
4.) Press Reset, only the h:inputText will be reset.

Use with mobi:comps -
/ICE-10114mobi.jsf has some mobi comps in a form. There seems to be no difference between the use of clear or reset with mobi:flipwsitch or dateTime spinners. There does not seem to be support for mobi:geolocation.

r47057: added "reset" capability to ACE, MOBI components

I had to add various mechanisms to solve specific situations, including a special flag to avoid applying the general clear algorithm to some elements; finding ways for lazy load components to register their default values without having to be initialized; sending additional context information for dealing with single and multiple radiobuttons and checkboxbuttons, and covering the case where the clear button is clicked first and then the reset button.

Testing notes: The testing matrix will be a little involved because of all the possible scenarios and configurations. Please test using the following criteria and combinations of, as feasible.

• Resetting the form before and after having interacted with the component.
• Components with and without ajax (with ajax, no requests to the server should be made).
• Input components with and without inField labels, if they support them.
• Check if the resetForm action reverts to the original value after having previously executed the clearForm action.

Note that for ace:fileEntry the reset action is the same as the clear action, since the component can't be loaded with preselected files to download.