Commits on Feb 25, 2017

1. Fixing a minor bug in Number validation. …

   The function validateNumber only checks for numeric values.
   
   **By PHP isNumeric**
   
   "42",
   1337,
   0x539,
   02471,
   0b10100111001,
   1337e0,
   "not numeric",
   array(),
   9.1
   
   **Will evaluate respectively**
   
   '42' is numeric
   '1337' is numeric
   '1337' is numeric
   '1337' is numeric
   '1337' is numeric
   '1337' is numeric
   'not numeric' is NOT numeric
   'Array' is NOT numeric
   '9.1' is numeric
   
   Grav though does not support all value types for a variety of reasons. One being YAML Blueprint definitions, where it makes sense to make a new type value for a more specialized format. Specifically for numbers if a more advance number format it would make sense to make a new type for that number format.
   
   YAML spec specifically allows both Integer or Float contexts, as seen in the validate class validateInt and validateFloat. This is useful when the output formats explicitly needs to be a certain format.
   
   However, in the case of generic numeric contexts, which numbers could be floats or ints dynamically, the values are cast back to an int currently in Grav numeric validation. Having dynamic primitive number formats is important, true in an interpreted language like JavaScript where 1 and 1.0 will both work for a number value.
   
   The reason to cast the type of the variable still is to prevent wide selection of number formats, and to keep Grav in line with primitive YAML field formats.

   

   coder4life committed Feb 25, 2017
   Configuration menu

   • View commit details
   • Copy full SHA for d1aee41
   • Browse repository at this point

   Copy the full SHA

   d1aee41 View commit details

   Browse the repository at this point in the history