Opened 7 years ago

Closed 6 years ago

#8144 closed feature (notabug)

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 (last modified by Scott González)

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.

Change History (6)

comment:1 Changed 7 years ago by Scott González

Type: bugfeature

This is not a bug. The documentation clearly states that these options require numbers.

We should consider adding globalization support to slider.

comment:2 Changed 7 years ago by Scott González

Description: modified (diff)

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).

comment:3 Changed 7 years ago by campbeln

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.

comment:4 Changed 6 years ago by Scott González

Milestone: 1.9.01.11.0

comment:5 Changed 6 years ago by davenaeder

Status: newopen

We will reevaluate this when we begin enhancing the slider component

comment:6 Changed 6 years ago by Scott González

Resolution: notabug
Status: openclosed

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.

Note: See TracTickets for help on using tickets.