Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[FIXED] number filtering broken for form input
07-21-2013, 05:52 PM, (This post was last modified: 07-21-2013, 07:23 PM by icedlava.)
#1
[FIXED] number filtering broken for form input
Hi,

There seems to be a problem with the current locale number filtering - it is broken for at least integer input .

The javascript regex seems to be the problem in MiscFunctions.js, preventing certain number input. eg can input 11 but not 10, 111 but not 102.

While i can turn off javascript to get around this, I've realized when I do this there does not seem to be fully implemented validation here for some number forms (is this really true or maybe something else broken?). In effect it is making it very error prone in use.

Is there a fix pending for this number filtering issue?

Thank you.
Reply
07-21-2013, 07:01 PM,
#2
RE: number filtering broken for form input
Hi, icedlava,

Thank you for your test and report.

Sorry for my mistake. The pattern used to validate overlooking the zero should be available after the first digit for integer.
Any feedback is highly appreciated to make it correct and more precisely.
Thans and Best regards!

Exson
Reply
07-21-2013, 07:14 PM,
#3
RE: number filtering broken for form input
(07-21-2013, 07:01 PM)Exsonqu_Qu Wrote: Thank you for your test and report.
My pleasure.
(07-21-2013, 07:01 PM)Exsonqu_Qu Wrote: Sorry for my mistake. The pattern used to validate overlooking the zero should be available after the first digit for integr
No need for sorry, it happens. Thanks for such a quick fix!

I do have some questions on the locale handling however.
Is there some reason for the javascript validation? Would it not be better to handle locales in general server side first with PHP in rigorous manner so it is working, and then progressively add js validation if required, to a plan utilizing current standards for HTML5/js progressive enhancement?

Perhaps there is an overall plan so excuse my ignorance if i have missed it.

Thank you again for your quick attention!

Regards,


Reply
07-22-2013, 03:15 AM,
#4
RE: [FIXED] number filtering broken for form input
Hi, Icedlava:

Not sure if you've read this article: http://www.weberp.org/wiki/TransitionToHtml5
The target is to validate users' input on client side. The number validation from the browser does not work. And webERP has a slim solution for different locale format. In order to make it harmony with the original server side solution, we enhanced tim's js solution, that's what you've seen now.
We hope that most problem can be found in client side, so the users will not be frustrated by information feedback from server.

Hope it clarify something.

Thanks and best regards!

Exson
Reply
07-22-2013, 08:17 AM,
#5
RE: [FIXED] number filtering broken for form input
Which field is not validated server side? I think we have fairly complete server side checks for number validation - is_numeric at least. But this is redundant for most with javascript now anyway as you point out. If you have come across a field that should be validated server side, but isn't that please do let me know.
Thanks
Phil Daintree
webERP Admin
Logic Works Ltd
http://www.logicworks.co.nz
Reply
07-22-2013, 08:33 PM, (This post was last modified: 07-22-2013, 08:40 PM by icedlava.)
#6
RE: [FIXED] number filtering broken for form input
(07-22-2013, 03:15 AM)Exsonqu_Qu Wrote: Not sure if you've read this article: http://www.weberp.org/wiki/TransitionToHtml5
The target is to validate users' input on client side.
Thanks Exson, i will try and help here.
(07-22-2013, 03:15 AM)Exsonqu_Qu Wrote: The number validation from the browser does not work. And webERP has a slim solution for different locale format. .....
...
We hope that most problem can be found in client side, so the users will not be frustrated by information feedback from server.
Yes this is what i noticed so wondering if we could implement stronger server side support for locale validations or if anything is planned here rather than javascript and only client side.

Many thanks for your help!


Hi Phil,

I had to turn off javascript as it was getting frustrating for the client due to some input validation issues client side as mentioned above. When I did we found that if the data input person made certain errors in input, it was not captured/alerted to them and incorrect values can be successfully input into the database.

eg for decimal, one example where comma is entered instead of decimal point in price entry:

23,04 results in 2,304.00 saved

Not sure what happens across all locales.

Cheers,
Reply
07-22-2013, 09:04 PM,
#7
RE: [FIXED] number filtering broken for form input
Well that's interesting... what do you think should be the best result when someone enters 23,04 when the decimal point should be a period (full stop.)?
I am not sure we can or should attempt to trap such errors?

In other locales this number would be interpreted as 23.04 if the decimal point is a comma. The thousands separator is ignored and removed from the string.

If the client is used to entering numbers using , as a decimal point then you can easily change her language setting to one that expects this - or modify includes/LanguagesArray.php to define the decimal point character for their preferred language.

Also, using the trunk in a live install could lead to some frustration for the client, especially as at the mo I am working on bringing html5 into quite a few scripts. It is certainly good to get the feedback on the cock ups though.
Phil Daintree
webERP Admin
Logic Works Ltd
http://www.logicworks.co.nz
Reply
07-23-2013, 11:24 AM,
#8
RE: [FIXED] number filtering broken for form input
Hi, Icedlava:

I don't know what kind of locale of your client used. Phil has initiated a project to support different locale's account number support around years ago, you can find more details here: http://www.weberp.org/wiki/MultiLanguageNumbers
Sometime it's important for users who do not use period as decimal point and comma for thousand separator to understand this topic.
The design for the js number validation now based on the rules on above project. such as 23,40 is not allowed except comma is used as decimal point which is defined by users' locale.

Maybe we should extend the file includes/LanguagesArray.php we are using to let more patterns are allowable.

If any further finding, please let us know it.

Best regards!

Exson

(07-22-2013, 08:33 PM)icedlava Wrote:
(07-22-2013, 03:15 AM)Exsonqu_Qu Wrote: Not sure if you've read this article: http://www.weberp.org/wiki/TransitionToHtml5
The target is to validate users' input on client side.
Thanks Exson, i will try and help here.
(07-22-2013, 03:15 AM)Exsonqu_Qu Wrote: The number validation from the browser does not work. And webERP has a slim solution for different locale format. .....
...
We hope that most problem can be found in client side, so the users will not be frustrated by information feedback from server.
Yes this is what i noticed so wondering if we could implement stronger server side support for locale validations or if anything is planned here rather than javascript and only client side.

Many thanks for your help!


Hi Phil,

I had to turn off javascript as it was getting frustrating for the client due to some input validation issues client side as mentioned above. When I did we found that if the data input person made certain errors in input, it was not captured/alerted to them and incorrect values can be successfully input into the database.

eg for decimal, one example where comma is entered instead of decimal point in price entry:

23,04 results in 2,304.00 saved

Not sure what happens across all locales.

Cheers,

Reply
07-23-2013, 11:45 AM,
#9
RE: [FIXED] number filtering broken for form input
Hi, Phil:

It seems a bug. I've input 23,40 in the demo and choose Chinese locale, the result is 2,340. Although this kind of input is illegal in js when we transit to html5. We should check what goes wrong.

Best regards!

Exson
(07-22-2013, 09:04 PM)phil Wrote: Well that's interesting... what do you think should be the best result when someone enters 23,04 when the decimal point should be a period (full stop.)?
I am not sure we can or should attempt to trap such errors?

In other locales this number would be interpreted as 23.04 if the decimal point is a comma. The thousands separator is ignored and removed from the string.

If the client is used to entering numbers using , as a decimal point then you can easily change her language setting to one that expects this - or modify includes/LanguagesArray.php to define the decimal point character for their preferred language.

Also, using the trunk in a live install could lead to some frustration for the client, especially as at the mo I am working on bringing html5 into quite a few scripts. It is certainly good to get the feedback on the cock ups though.

Reply
07-23-2013, 11:50 AM,
#10
RE: [FIXED] number filtering broken for form input
Hi, all:

I've checked the server side check. If we want to prevent this from input, a regex pattern should be defined at server side php scripts too just like the js doing in client side. Otherwise, we cannot sort this kind of errors out.

Best regards!

Exson
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)