Validate integer value parameters

[kamenov]

Make sure that values expected as int are int before they are used. i.e.

my $line_w = defined $arg{'border'} ? $arg{'border'} : 1 ;

IF $arg{'border'} equals 'blabla' THEN $line_w = 'blabla' AND error will be thrown upon first use.

[PhilterPaper]

Yeah, this sort of validation for settings values should probably be done, especially for data type. I'll throw it in the hopper for an upcoming release.

[PhilterPaper]

Something like:

• for globals (not determined by find_value() call), a validate_field(value, type, range) call
• for settings that go through find_value(), add parms to pass to validate_field()

The object would be to flag a problem setting as early as possible, before it possibly gets used in determining default/fallback for other settings. Perhaps the parameters could include a fallback value if an invalid one was given? It would still have to output an error message, but at least PDF::Table could run with reasonable results and no system errors. It could be tricky to do compound settings such as 'h_rule_w' falling back to 'rule_w', where 'rule_w' is found to be bogus. To minimize annoyance, each bad setting should probably be limited to one error message, even though it may be used many times (such as once each cell in find_value()). However, if 2 different settings (e.g., 'rule_w' => -1 in one place and 'rule_w' => 400 in another) have different bogus values, they should probably both be flagged.

This doesn't have to be limited to integers. It could check for valid floats and strings too. The allowed 'range' might include minimum and maximum values, minimum only (e.g., 0 for border and rule widths), multiple sub-ranges, and even enumerated values. For strings, it would probably have to be an enumerated list of valid values. True/False booleans would probably be best listed as enumerated lists 0 and 1, rather than a range, and might even allow 'T'/'true'/'yes'/'F'/'false'/'no' to be converted to 1/0.

[PhilterPaper]

Here is a possibility. Call a validation routine after deprecated names are modified to supported names, and before any settings are actually used. Go through global, row_props, column_props, cell_props like find_value does. An array of validation settings would be defined:

@validation = (
  {  # one entry, for rules and borders
     names => [ 'border_w', 'h_border_w', 'v_border_w', 'rule_w', 'h_rule_w', 'v_rule_w' ],
     type => number | int | float | string | bool | color ,  # here number
     # optional settings:
       min => minimum value, NOT included (min < x),
       Min => minimum value, inclusive (Min <= x),   # here, 0
       max => maximum value, NOT included (x < max), 
                      # perhaps something like 100 reasonable for most applications?
       Max => maximum value, inclusive (x <= Max),
       enum => [ 'list', 'of', 'permitted', 'exact', 'values' ],
       multi => [ {min/Min=>, max/Max=>}, {min/Min=>, max/Max=>},... ],  # multiple ranges, one must be true
       regexp => 'regular expression to validate a string', 
                      # e.g., alpha + 0 to 5 alphanumerics: '^[a-zA-Z][_a-zA-Z0-9]{0,5}$'
       replace => value to use if invalid setting given (still give error message?),
       default => default value if no setting given?,
  },
  { # some other setting  }, ...
              );

bool would get special treatment, permitting only 0/N/No/Off/F/False (converted to 0) and 1/Y/Yes/On/T/True (converted to 1), case-insensitive. min/max/enum/multi entries would be ignored for boolean.

A string could have enum for a list of permitted strings, or a regexp for permitted patterns. I'm not sure that min/max for a string would make sense, although it could be done with lt, le, eq, ge, gt (would be case sensitive).

A regexp would be anything digestible by Perl regexp "=~" match. Are there cases where multiple regexps would be needed (with pass if any matches), or can the appropriate flags handle this? How about "must NOT match" with !~ ? That might well need multiple regexp's, with all must pass.

How about multi ranges where the value must not fall into any of the ranges? Perhaps a generalized multi test (not just min/max) would be good, where the value must pass one|any|all|none of the subtests?

A color type would check for a legitimate numeric/hex code (a number of formats), and might check names against a standard list (built-in or provided). An enum list might be added to further restrict allowed values.

This might be overly elaborate, but it probably covers the waterfront. int is necessary, and number could allow either an int or a float (clearer than forcing a float to be used?). Or, just int|float (no number), with integers permitted for float fields. Only one of 'min' or 'Min' could be used at a time, and likewise for 'max'/'Max'.

I think all settings are currently scalar values. If any lists are added, size limits would have to be added. Mixed arrays (different type elements) could be rather difficult, but still possible. The first release could have "scalar" only, architected to support arrays, hashes (?), and mixed arrays later as a wrapper around the scalar checks. Have a flag to support quitting on the first failure, or going all the way through.

Perhaps a clip or constrain flag to force a value to be within the min/max range if it's found outside it. For 'min' (or 'max') not-inclusive, what should be used if <= min, and a float? If multi ranges, would have to pick closest range.

A limit value that is a formula instead of a fixed value. For example, a border width upper limit that is proportional to the table width and/or height. This would entail eval'ing a formula to get a scalar value. It might even be a CODE reference to a routine, so, say, a selected rule color could be checked that it's not close to any cell background that it touches? I can't see trying to validate a text color or background based on the text value (e.g., negative, or an ERROR is being indicated), as that would be a cell-specific setting. You would just have to set up the color correctly for the text being used.

A test which is a pointer to a user-supplied routine to test the value(s). This could be an elaborate comparison and not just some simple yes/no tests against fixed values, but against other setting values and such. It could also do multiple tests against a value, rather than just one test as here, possibly including recursive tests using this test system, so you don't have to reinvent the wheel.

If dashed rules, or background patterns, are added, some means to validate them.

[PhilterPaper]

Before I go and write a validation routine incorporating the thoughts above, I see that there are a number of data validation packages on CPAN. Can anyone recommend one or another? I would like to avoid requiring loading of a heavyweight package (unless it's already Core), and prefer Core to non-Core packages. The idea is avoid requiring yet another prerequisite package if I can help it, especially if it's non-Core. Any experiences to report?