On Tue, Jun 23, 2009 at 1:47 PM, Thomas Weidner<thomas.weid...@gmx.at>
wrote:
Jason,
But when you have a german user then he will enter "1.000,50"
Your server is configured to english and accepts only "1,000.50"
So whatever your user enters, it does not validate because you expect
always
english regardless of what the user really does and where he lives.
Your expectation of "native integer" does not work when you have a
application which is accessed from users all around the world.
Many times this expectation IS valid. One such case would be integer
database row identifiers. I guess I expected Zend_Validate_Int to
behave consistent with the PHP function filter_var($x,
FILTER_VALIDATE_INT). I don't want to add Zend_Filter_Digits
specifically because with the examples you gave above it the validator
would be run on the value '100050' which is quite different from
1.000,50 or 1,000.50.
I was definitely surprised when I upgraded to 1.8 that I suddenly had
to explicitly disable caching on Zend_Locale even though my projects
don't even use the locale directly. I thought the exception I was
getting was a problem with the cache that I was using in my own code,
until I stepped through the stack trace and saw that it originated in
Zend_Locale and not in my own class.
The computional/english notation and the notation without dots is always
accepted regardless of the locale where you are or which you request.
But this has nothing to do with the cache problem.
And I never said that a filter has to be applied to validate a input.
Why would a string like 1.000,50 result to 100050 ?
There is nothing in the validator which erases separation and fraction at
the same time.
I am quite confused to what you've stated here.
A validator does not return a value, only true or false.
Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com
