Argh. Hit the wrong key and the message gets sent before it's ready.
At any rate, the discussion got me to look at the filters and
validators again and to try some things out.
$x = '1,500';
Zend_Debug::dump(Zend_Validate::is($x, 'Int'), 'Is Int in ' .
Zend_Version::VERSION);
// Is Int in 1.7.0 bool(false)
// Is Int in 1.8.0 bool(true)
I can see a value to locale aware validation in some cases, but this
is a change in behavior from version 1.7 to 1.8 such that if I had
intended an application to reject '1,500' and it did so in 1.7, it
will now be accepted in 1.8.
Andrew
On Tue, Jun 23, 2009 at 2:55 PM, Andrew Ballard<aball...@gmail.com> wrote:
> I believe Matthew suggested throwing a digits filter on up front.
> Perhaps I misunderstood and he was talking about the internal workings
> of the validator itself such that
>
> if ($value = Zend_Filter::get($value, 'Digits')) {
>
>
> On Tue, Jun 23, 2009 at 2:51 PM, Thomas Weidner<thomas.weid...@gmx.at> wrote:
>>> 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
>>
>
