Introduced validateOn attribute for client validation components. The attribute takes an event name (such as click, blur or mouseout). Implemented also functionality that triggers validation on specified event.

Remains to implement multiple event validation triggering per component.
Add support in complex components for focus related events.
Determine if we need to disable default events used for validation when validateOn is specified.

Would this feature work with any JS DOM events, or just actual component client behaviour events that the component supports?

Yes, any JS DOM event should work.

Remains to implement multiple event validation triggering per component.

Yes, this would be useful since any supported DOM events can be used.

Determine if we need to disable default events used for validation when validateOn is specified.

Yes, if you specify custom events it should override the default ones.

Implemented multiple custom event validation and automatic disabling of validation on default event.
The custom events that trigger the validation can be defined as a space separated list of event types into the validateOn attribute:

<ace:clientValidateRequired validateOn="blur click keyup"/>

It turns out that I missed checking in the modified JS code for the client validators. Please re-test.

ICEfaces 4 trunk r49171.
Initial re-testing with ace:textEntry using clientValidators shows the events are now functioning as expected. Further testing will be carried out with additional ace comps and validators.

ICEfaces 4 trunk r49171
The ace:maskedEntry component works differently than other components such as textEntry and textAreaEntry when using the validateOn attribute.
When using validateOn=blur there is no difference from the other components, meaning you can fire validation by entering any number of characters into the mask then blur away.
When using validateOn=click or keyup (and possibly other events) the mask must be completely filled before the validation is fired. This makes validators such as clientValidateLength and clientValidateRequired seem incompatible with maskedEntry when used in this way.
Is this the expected behaviour?
QA test application ICE-10883.jsf, ICE-10883-2.jsf, ICE10883-3.jsf are found at:
http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/maskedEntry

ICEfaces 4 trunk r49171
The validateOn events tested (blur, click, dblclick, keyup, contextmenu) do not function at all when used with a client validator inside an ace:comboBox, ace:selectMenu or with ace:checkboxButtons.

QA test application ICE-10883.jsf, ICE-10883-2.jsf, ICE10883-3.jsf are found at:
http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/comboBox

QA test application ICE-10883.jsf found at:
http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/selectMenu

QA test application ICE-10883.jsf found at:
http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/checkboxButtons

ace:maskedEntry, ace:comboBox and ace:checkboxButtons components are more complex components that need additional infrastructure that will provide information to jQuery Validation on what elements need to have the event handlers registered on.

ICEfaces 4 trunk r49183
All ace client validators except ace:clientValidateRequired can be triggered with a blur event regardless of what the validateOn attribute is set to.
This can be seen in the /ICE-10883.jsf, /ICE-10883-1.jsf, /ICE-10883-2.jsf test apps located at
http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/textEntry

Modified clientvalidator.js code to disable default event listeners for the entire form (it is not possible to disable default events for each element with the current API). This means that when any of the client validators will use validateOn attribute then the rest of the validators will need to define the events to respond on as well.

Disable default event handlers used to run the validation only when the validated element has custom event validators defined. This in effect removes the restrictions described in previous comment.

Capture custom events on the focusable element of the component when possible to ensure validation is triggered on the components with more complex markup.

Tested with ICEfaces 4 trunk r49216. Tomcat 8, FF 47, Chrome 53, IE 11.
There are still issues outstanding.

ComboBox
validateOn = keyup does not validate after the first keystroke. Two or more keystrokes are required to file validation where necessary.
Test app: /comboBox/ICE-10883.jsf

maskedEntry
The length validator does not function properly when used with validateOn unless the mask is entirely filled. This seems to be an incompatibility.
Click and keyup events do not work consistently. Sometimes they only function after the form has been submit.
The Required validateOn=blur message is seen while the submit button is pressed but is removed when the button is released.
Test app: /maskedEntry/ICE-10883.jsf

checkboxButtons
When testing Required validateOn=click The Required validation message is displayed after making a selection. To remove the message the form must be submit.
When testing Length validate on blur/click, the validation messages are not removed after fulfilling the requirement and using blur or click.
Test app: /checkboxButtons/ICE-10883.jsf

Fixed ComboBox component client validation by applying validation on the actual user modified input element instead of the hidden input element used by the client side code for holding the value.

• maskedEntry
  This component is incompatible with all the client validators. Any of the potential client validation constraints are already incapsulated by the component's client code.

• checkboxButtons
  This component is incopatible because it has multiple elements that need to have their state tracked by events listeners. This is not currently doable with the jQuery Validation API.

We'll need to document the limitations for these components.

Verified ace:comboBox issues fixed ICEfaces 4 trunk r49310. Tomcat 8, MS edge, IE 11, 10, 9, FF 47, Chrome 53.

Re-opened.

Can the TLD description for the validateOn event be expanded a bit to further explain the type of events supported (DOM events?), and also the fact that when used these events override the default events used to trigger the validator, etc. ?

I added notes to the Wiki page for ace:maskedEntry indicating that client validators are not supported with it.

Explained better how 'validateOn' attribute can be used.