Created a simple test to verify the current behaviour of the ACE input components when "resetted" using a typical HTML form reset:

<h:commandButton id="reset" value="Reset Form" type="reset" immediate="true" />

Results show the input field value being cleared successfully on the following components:

• ace:textEntry
• ace:autoCompleteEntry
• ace:comboBox
• ace:dateTimeEntry

The following components input field values were unaffected by the HTML reset:

• ace:textAreaEntry
• ace:selectMenu
• ace:simpleSelectOneMenu
• ace:maskedEntry
• ace:sliderEntry
• ace:checkboxButton
• ace:radioButton

Another test scenario was created using a slightly more sophisticated JS technique to dynamically clear the component values:

function clearForm(oForm) {
  var elements = oForm.elements;    
  oForm.reset();
  for(i=0; i<elements.length; i++) {
	field_type = elements[i].type.toLowerCase();
	switch(field_type) {
		case "text": 
		case "password": 
		case "textarea":
	        case "hidden":	
			elements[i].value = ""; 
			break;
		case "radio":
		case "checkbox":
  			if (elements[i].checked) {
   				elements[i].checked = false; 
			}
			break;
		case "select-one":
		case "select-multi":
            		elements[i].selectedIndex = -1;
			break;
		default: 
			break;
	}
    }
} 

Results show that this technique clears all same components as the HTML reset, and adds these additional components:

• ace:textAreaEntry
• ace:simpleSelectOneMenu
• ace:maskedEntry

The following components remain unaffected:

• ace:selectMenu
• ace:sliderEntry
• ace:checkboxButton
• ace:radioButton

As part of ICE-5377 Mircea implemented a new "Validateable" interface on the ACE input components. This interface provides support for the getValidatedElementId() method, which returns the client ID of the component element that contains the component's value. The original intent of this interface was to enable JS-based client-side validators access to the value-holding element for each input component. However, it may be feasible to also leverage this interface to allow an enhanced reset JS function to determine the correct element to clear in order to reset each component.

Note that this approach may be effective in most cases, but would not provide a way to also reset the state of the components JS model objects.

For this release at least, I would suggest that only the following comps in the "Not Sure" list support reset:

• ace:fileEntry (this appears to reset now via the std. form reset function but multiple selection mode might require advanced reset features to clear).
• mobi:geolocation (the demo already has a "Reset Values" button so the reset function should the same thing as that button).
• I don't think there is such a thing as ace:geolocation ?

r46509: added reset capability to ACE components.

This capability is used by calling the function ice.ace.resetForm(form), where the 'form' argument can be the client id of a form or a form node.

The approach used for this feature is to render a data-ice-reset attribute on the root node of a component, containing the reset settings for that specific component. The global ice.ace.resetForm(form) function searches for elements containing this attribute and invokes the respective component-specific reset functions passing the settings contained in said attribute, but first the logic in the clearForm() function posted above is executed to reset h:* components and regular input elements. This logic was extended to avoid clearing form-specific hidden input fields like ice.view and ice.window.

Testing notes: The testing matrix will have to be somewhat complex. We want to test this feature with and without inField labels (if the component supports them). We also want to test with and without ajax (just the default event). And we also need to test when the components are loaded without a programmatically predefined value and when they are loaded with one.

We want to make sure that the components are reset successfully and we also want to make sure that, after submitting the form right after resetting, components don't submit the value they had (or any value for that matter). Another thing to test is that calling the resetForm function doesn't trigger any request to the server (make sure that the button used to invoke this function doesn't submit the form itself). And, of course, we want to make sure that after resetting a component, it keeps working normally and the user is able to input another value.

r46513: added reset capability to MOBI components and ace:fileEntry

The components that now support the reset capability are the following:

Input

• ace:autoCompleteEntry
• ace:dateTimeEntry
• ace:maskedEntry
• ace:richTextEntry
• ace:sliderEntry
• ace:textAreaEntry
• ace:textEntry
• ace:fileEntry

Buttons

• ace:buttonGroup
• ace:checkboxButton
• ace:checkboxButtons
• ace:radioButton
• ace:radioButtons

Selection

• ace:comboBox
• ace:selectMenu
• ace:simpleSelectOneMenu

MOBI input

• mobi:dateSpinner
• mobi:timeSpinner
• mobi:flipswitch
• mobi:geolocation

As per ICE-10115, now ace:pushButton and ace:linkButton have a 'reset' attribute. When true, the buttons invoke the ice.ace.renderForm(form) function for the form in which they're contained. So, now they can be used for testing this JIRA.

r46528: removed restriction of only resetting ace:dateTimeEntry in popup mode, since it's also possible to reset it in the calendar mode

ICEfaces 4 trunk r46527. Initial testing with ace:radioButtons appears to be failing. When the page loads radioButton 1 is selected.
After selecting radioButton 2, then pressing the Reset button, no radioButtons are selected. Should this reset to radioButton 1 selected?
When selecting another radioButton the following message is seen:
form1:radioButtons1: Validation Error: Value is not valid

This occurs with and without ace:ajax inside the ace:radioButtons.

r46547: added a mechanism to persist values in ace:radioButtons, since the component relies on the individual radio buttons holding the same value all the time and only applying the name attribute to the selected radio when submitting

r46548: changed name of resetForm() function to clearForm(), in order to implement in the future an actual reset functionality that restores original values

Verified ICEfaces 4 trunk r46549. ace:radioButtons issue is resolved.
QA test apps using the new attributes for ace:linkButton and ace:pushButton have been checked in.

/ICE-10114.jsf and /ICE-10114mobi.jsf
http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/linkButton
http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/pushButton

r46907: added logic to cover the case when the label is inField and there is an indicator whose position is labelLeft or labelRight, in order to make sure to restore both the label and the indicator in the field
r46908: committed fix to 4.1 tag

ICEfaces 4.1 TAG r46909
There are issues in the scenarios ace:maskedEntry and ace:selectMenu with label="inField" and indicator position= labelLeft or labelRight...

1.) ace:maskedEntry
When the page is first loaded the optional indicator does not show next to the label when the label is inField.
In the QA test app the markup is as so:

 <ace:maskedEntry id="maskedEntry1" mask="***********"
                value="#{pushButtonResetBean.value2}" label="maskedEntry"
                labelPosition="inField" optionalIndicator="(*)"     indicatorPosition="labelLeft" /> 

Once you have pressed the Clear button the optionalIndicator is shown at the left of the inField label. as expected.

2.) ace:selectMenu
When the page is first loaded the label and optionalIndicator are shown as expected.
After selecting a value from the menu, then pressing the Clear button, the selectMenu no longer displays the label or optionalIndicator.

The QA test apps have been modified and checked in.

The first issue is not caused by this recent commit. It seems to be a general issue that we hadn't tested before. Please test to see if it happens before this commit.

The issue seems to be that the asterisk and the brackets of the indicator are being interpreted as part of the mask. if you change the mask to only numbers (e.g. 9, 999, or 99/99, etc.), then you will see the asterisk and the brackets as part of the infield label. For now try testing this feature without using brackets or asterisks.

Confirmed that the first issue also happened in the past.
Confirmed that changing the mask type to 9999999 allows the optionalIndicator to be shown inField on page load.
Test apps were updated to reflect that change.

Ok, the second started with an earlier commit, but was discovered with these new tests. If an ace:selectMenu component has an f:selectItem with the empty string as the value, it will show that value (i.e. blank) instead of the inField label.

Actually, it wasn't caused by a recent commit. It's just the way it has been working all the time. I suggested to add an empty string value in ICE-10900 to avoid validation errors. This is just the way it logically works.

We would have to introduce a special value to represent a state where the user hasn't interacted yet with the component, in order to show the inField label after clearing the form when there exists an empty string value, but perhaps it would be risky to do so at this moment.