Search and Top Navigation
#8144 closed feature (notabug)
Opened February 29, 2012 02:02AM UTC
Closed April 16, 2013 08:16PM UTC
Min, Max & Step not being forced into numeric values
Reported by: | campbeln | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 1.11.0 |
Component: | ui.slider | Version: | 1.8.18 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
If the values for Min/Max/Step are not forced into numerics at .slider creation by the caller, then the following error occurs (in Chrome):
Uncaught TypeError: Object xxxx has no method 'toFixed' (jquery-ui-1.8.18.custom.min.js:169)
The slider itself reacts oddly to drag events in this state (going out of range, etc), yet when a value is typed into its associated INPUT[type=text] (see code below), the ranges are properly enforced!?! Values >500 and <1 are reset to the bound!!?
So it looks like the data validation part of the Slider code forces numeric values on the Min/Max/Step while the UI portion does not.
Attachments (0)
Change History (6)
Changed February 29, 2012 12:47PM UTC by comment:1
type: | bug → feature |
---|
Changed February 29, 2012 12:50PM UTC by comment:2
description: | If the values for Min/Max/Step are not forced into numerics at .slider creation by the caller, then the following error occurs (in Chrome): \ \ {{{ \ Uncaught TypeError: Object xxxx has no method 'toFixed' (jquery-ui-1.8.18.custom.min.js:169) \ }}} \ \ The slider itself reacts oddly to drag events in this state (going out of range, etc), yet when a value is typed into its associated INPUT[type=text] (see code below), the ranges are properly enforced!?! Values >500 and <1 are reset to the bound!!? \ \ So it looks like the data validation part of the Slider code forces numeric values on the Min/Max/Step while the UI portion does not. \ \ Please see demo code below: \ \ {{{ \ <link href="jquery-ui-1.8.18.custom.css" rel="stylesheet" type="text/css" /> \ <script src="jquery-1.7.1.min.js" type="text/javascript"></script> \ <script src="jquery-ui-1.8.18.custom.min.js" type="text/javascript"></script> \ \ \ <input type="text" id="sliderInput" /> \ <div id="slider"></div> \ \ \ <script> \ function WireUpSlider(sSliderID, sInputID, sMinMaxStep) { \ var a_iMinMaxStep = sMinMaxStep.split('|'); \ \ $(sSliderID).slider({ \ range: "min", \ min: a_iMinMaxStep[0], //# Requires parseInt(a_iMinMaxStep[0]) \ max: a_iMinMaxStep[1], //# Requires parseInt(a_iMinMaxStep[1]) \ step: a_iMinMaxStep[2], //# Requires parseInt(a_iMinMaxStep[2]) \ value: $(sInputID).val(), \ slide: function (event, ui) { \ $(sInputID).val(ui.value); \ } \ }); \ \ $(sInputID).change(function () { \ var iValue = parseInt(this.value); \ if (!isNaN(iValue)) { \ $(sSliderID).slider("value", iValue); \ } \ //# rely on the .slider to enforce the range \ this.value = $(sSliderID).slider("value"); \ }); \ } \ \ WireUpSlider("#slider", "#sliderInput", "1|500|1"); \ </script> \ }}} → If the values for Min/Max/Step are not forced into numerics at .slider creation by the caller, then the following error occurs (in Chrome): \ \ {{{ \ Uncaught TypeError: Object xxxx has no method 'toFixed' (jquery-ui-1.8.18.custom.min.js:169) \ }}} \ \ The slider itself reacts oddly to drag events in this state (going out of range, etc), yet when a value is typed into its associated INPUT[type=text] (see code below), the ranges are properly enforced!?! Values >500 and <1 are reset to the bound!!? \ \ So it looks like the data validation part of the Slider code forces numeric values on the Min/Max/Step while the UI portion does not. \ |
---|
I've removed the code example in the ticket description. Please do not paste large blocks of code into a ticket (see the red box telling you not to for more info).
Changed February 29, 2012 10:50PM UTC by comment:3
Apologies, but I did not believe that ~20 lines of code was "a large block of code". It was primarily presented to show the valid reason why I was passing Strings into the Number-based values.
As to the documentation, yes it says "Number" and goes further to describe these values as being "numeric" in nature. Yet the behavior of the Slider is completely inconsistent as .value (also stated that it must be a number) is quite happy to get a value from a Textbox (a string), and again the data validation code in Slider is happy to cast the Number-based values, while the UI portion freaks out.
With this approach, I will be forced to write "condom code" around the calls to .slider(...) when it could very easily scrubbed inside the code (which is being done in some of the code, but not all of it). If you want to go with the "Feature" description, then the casting present for .value and within the data validation portions of the Slider should be removed, because as it, the behavior is inconsistent (and therefore not very Feature-like).
It was due to this inconsistency that caused me a half day's work to identify the reason for this inconsistent behavior.
Changed October 11, 2012 02:53PM UTC by comment:4
milestone: | 1.9.0 → 1.11.0 |
---|
Changed October 15, 2012 04:50PM UTC by comment:5
status: | new → open |
---|
We will reevaluate this when we begin enhancing the slider component
Changed April 16, 2013 08:16PM UTC by comment:6
resolution: | → notabug |
---|---|
status: | open → closed |
I'm going to close this since it's now misleading. We will not do the conversion. I changed it to a feature ticket because of support for Globalize. But that shouldn't happen until the Globalize refactor and if we add support for it (which I'm not sure we need to), then it should be in a new ticket with a clear purpose.
This is not a bug. The documentation clearly states that these options require numbers.
We should consider adding globalization support to slider.