By the way, the regex I'm using restricts to maximum of 2 digits before decimal point plus, 1 or 2 optional digits after (if there is a '.').

Thanks,

Gez

All this is absolutly normal.

DECIMAL(4,2) means
- 4 digits in total
- 2 decimal (after .)

So, 2 digits before the point, and 2 digits afters.

If you overflow the 2 first digits (integer part), mySQL cannot deal with it and output the maximum available, wich is the closest value, and tells the user it has reached the maximum.
So what to do ? I don't know...

do not allow your user to insert more than 2 digits before the point.


I do not encounter this issue.
When you click 'Save', the form is always validated, whatever you have left the focus or not.

For the moment I still cannot see your issue.

Can we make a point on this and telling me exactly where is the problem ?

I would like to help you and close this.

Regards.

Hi @admin,

Here we go... The issue I'm getting at the moment is concerning 2 different decimal fields in the jstore social project. Just to be clear, in both cases, the regex allows for an optional 1 or 2 digits to be entered after a decimal point for all numbers greater than 1 AND, in the case of values beginning with 0, a .1 or greater must be entered. Furthermore, a decimal point cannot be added without at least one digit following it so 1. would invalidate.

1. The first field is price in the products table - a decimal(8,2) with a custom regex that prevents the user from entering more than dddddd.dd. The regex is:

   //Handler: price8prec2scale
   ^(0?(\.(0[1-9]|[1-9]\d{0,1}))|[1-9]\d{0,5}(\.\d{1,2})?)$

   This allows a minimum value of 0.1 where the user can enter .1, .10, 0.1 or 0.10 AND a maximum value of 999999.99.
2. The second field is value in the discounts table - very similar to the first and is used for storing a percentage value for a discount - a decimal(4,2) with a custom regex that prevents the user from entering more than dd.dd. The regex is:

   //Handler: discountpercent0pt1to99pt9
   ^([1-9]\d?(\.\d{1,2})?|0\.[1-9]\d?)$

   This allows a minimum value of 0.1 where the user can enter 0.1 or 0.10 AND a maximum value of 99.99.

The Issue
In both cases, my issue seems to be when entering digits without a decimal point (.) and a trailing digit or 2 digits. They both fail to invalidate with jQuery unless I enter precision + 2 digits so, in case 1, entering 1234567890 OR 9000000000 will get invalidated by jQuery as will 123456 OR 900000 in case 2.

However, in case 1, products, if I enter any of the following, the result is that I get no validation error and the greatest value (999999.99) is saved. Values: 1234567, 9999999, 123456789. But, my regex only allows a maximum of 6 digits before a decimal point if there is one and, if there is a decimal point, there must be at least one digit after it with a maximum of 2 digits. As I said previously, this saves regardless with no validation message from jQuery.

In case 2, the behaviour is similar so that entering 100, 1234, 12345 OR 99999 will save a value of 99.99.

By the way, in both cases, trying to save 0.01 invalidates with jQuery as it should and so does trying to save 100.00 in case 2 or 1000000.00.

Hope this helps to further explain things and thanks again for the help!!!

Gez
***********ADD************
Also, in case 1, if I try to add a price beginning 0 but just entering say, .11, the value stores as 11.00 instead of 0.11 - therefore, I will change this regex to force the user to enter the 0 in this particular case.

Case 2
DECIMAL(4,2) :
Minimum value : 00.00
Maximum value : 99.99
If you enter 100, 1234 or anything else superior to 2 digits (integer part), it will fail. Normal.

You must understand that the maximum allowed digits BEFORE the point is (4 - 2) = 2.

Absolutly normal.

Case 1 idem.
If you want to allow 1234.xx, means 4 digits in the integer part : DECIMAL (6,2)



So it means that you have a regex problem, not a php problem.
I am not a guru on regex, so I don't know.

I can only say that I still see a '\d' wich is not allowed in javascript. Cook converts but it is not exact science.
Try to write an exclusive javascript regex. It will be supported for PHP.
The opposite is not.

So, try your regex in js separatly of Cook first.

No problem for the PHP part. Precision + Scale are OK

Hi @admin,
admin wrote: Sure, I completely understand the precision/scale...

The issue is that the user entering 100 into case 2 (decimal 4,2) doesn't get invalidated... Similarly, in case 1, the user entering 1000000 doesn't get invalidated... In both cases they just save.

As I said earlier, this is not a case that the regex is not working as I've tested this in a pure JS Validation tool - regexpal.com/

Please, try it... If you use the regex tester by pasting the regex into the first field, any entries in the second field that are valid are highlighted yellow. Any of the values that aren't allowed won't get highlighted.

This must be something to do with the way cook is converting the regex as it works fine both in the tester above and in the builder. None of the above mentioned entries that are incorrect are allowed in either.

Thanks,

Gez

*******ADD********
I don't believe that \d needs to be convertedfor JS regex as it works perfectly in the builder and regexpal site

Hi @admin,
Just tested the expressions in another JS Regex Validation engine which validates all of the correct formats fine. Please, give it a try at tools.netshiftmedia.com/regexlibrary/ and you'll see, there's no problem with it at all.

Screenshot of it:

Enter ^([1-9]\d?(\.\d{1,2})?|0\.[1-9]\d?)$ in the first field and try to enter 100 in the form, it invalidates it immediately.

This must be the way cook is handling them as \d \w \s all are valid in JS. The reason that a \d wouldn't work in an inverted case is that it would need to be swapped to a \D that matches any non-digit character.

Thanks,

Gez

Ok. Really interresting about \d I am confused because I never got them working.
Good Tool Thanks !

Once you've loaded your form, can you output the generated JS and dump here the regex for that handler ?
You can find it in the top of the file.

I am pretty sure that it is different...

So, then, you can try this generated regex in this tester

For sure, we can find the error. step by step.

Sure, give me a minute, I'll post it now.

Thanks,

Gez

What I input: ^([1-9]\d?(\.\d{1,2})?|0\.[1-9]\d?)$
In the form: ^([1-9][0-9]?(\.[0-9]{1,2})?|0\.[1-9][0-9]?)$

Yes, \d seems to have been converted.

Gez

EXACTLY !

This is because I was sure that JS was not handling this ... shame on me...

Before to change anything, can you comment the lines responsables of this :
helpers/html/validator.php - LINE 54

Sure, give me a minute, I was currently only working in sandbox.

just need to load up local server.

BRB

Thanks,

Gez

OK, sorry about that, I had to reinstall...

Works perfectly with those 2 lines commented out!

I think I love you

Thanks!

Gez

That's amazing !!

I love you too because I can close this topic now. Stess is gone...

But, I don't know what to do because I had to put these line for a reason I cannot remember.
I think I'll keep the lines commented for future. And then, let see ...

Thanks Jocelyn!

BTW, I think when you said before that \d \w \s weren't working when you invert match, I just double checked on this.

In this case, any instances of \w \d or \s would need to be converted to UPPERCASE \D \W \S which means NOT digit, word and space. Maybe that's the issue you were running into, eh?

Anyway, Thanks again for all your help!

Gez

Yes, but the best is when the component do not try to intervent on the the regex.
If somebody want to do such inversion, he just has to do it manually.

For the moment, Cook was not dealing with that.
Are \D \W \S handled in PHP ?

If in future we detect some incompatibilities between JS and PHP, the solution I will offer will be to be able to write a second regEx for JS, just under the PHP one in the rule file. A second facultative declaration.
I think it is the best. It will be declarated twice, but in the same place, so acceptable.

Love working with you my friend.

K+2, yeah !