Added stepPercent property to sliderEntry component, which has a default value of 10%. The idea being that, instead of specifying a fixed step value, or worse yet keeping the old hard-coded value of 5, the stepping will now automatically adjust to the range (max-min), and be a percent of it. Also, now it will go through the full range, and not get stuck just before the end.

The challenges in solving this were:

1. The component was caching a stale min and max value, so was not adapting to them changing. Addressed in ICE-6530.

2. Due to how YUI internally represents the slider value, it exacerbates application errors of misconfiguring the range with the length and the stepPercent. This is addressed in ICE-6532.

Adding the functionality to the component:
trunk
Subversion 23939
Subversion 23941

Modifying ace-showcase to demonstrate the functionality:
trunk
Subversion 23940

We may want to implement a delayed-submit algorithm for the slider keyboard functions, similar to that used on the ice:selectManyList component. The issue arises when you have a sliderEntry in singleSubmit=true mode, and you use the keyboard to change the slider value rapidly (many keypresses in a row). Each keypress will trigger a singleSubmit, and the latency of that will sometimes reset the slider value back to match the response from a previous singleSubmit, even though the user has already moved it past that on the client.

By delaying the singleSubmit until the user quits pressing keys for an internval (300ms?), we can avoid flooding the server with singleSubmits and also the strange "snapback" problem.

It does have that mechanism already. The timeout is hardcoded to 300ms. If you press an arrow key again within that time frame, then the original submit won't happen, so that only the last one will. We could expand the timeout to a larger time, or make it configurable.

I was wanting to change from using keydown to using keypress, so that we'd get auto-repeated events for when users hold the arrow keys down. But, this article shows that's not possible.

--------
http://unixpapa.com/js/key.html

There are many other special keys on a typical keyboard that do not normally send characters. These include the four arrow keys, navigation keys like Home and Page Up, special function keys like Insert and Delete, and the function keys F1 through F12. Internet Explorer and WebKit 525 seem to classify all of these with the modifier keys, since they generate no text, so in those browsers there is no keypress event for them, only keyup and keydown. Many other browsers, like Gecko, do generate keypress events for these keys, however.
--------

Then it further shows that special keys auto-repeat keydown in Internet Explorer and WebKit 525+, and most browsers, just not Gecko on OS X. Which is the browser we generally use in-house. So, I confirmed that auto-repeating does work in WebKit on OS X, without any code changes. We may only have to change the event in that one scenario.

Since Firefox on OS X is the only one that does not auto-repeat the arrow keys, we'll leave it as is. Verified in IE and Firefox on Windows that it works properly.

Icefaces2 trunk revision# 23979
Server: Tomcat6
Browser: FF3.6, IE6,7,8 & Googlechrome8
Application: ace-showcase

The feature tested successfully on all browser.

But on IE6 & IE7 the user is not able to tab into slider component field. I had to click on the slider component first before using the keyboard to change slider value.