Zend Framework

Custom Validator Messages may be broken

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Not an Issue
  • Affects Version/s: 1.9.1
  • Fix Version/s: 1.9.2
  • Component/s: Zend_Validate
  • Labels:
    None

Description

Hello all,

I just finished pulling my hair out trying to figure out why my following code failed to set custom error messages.

$email = new Zend_Form_Element_Text('email');
$email->setRequired(true)
->setDecorators(array('ViewHelper',array('JQueryErrors', array('placement' => 'prepend'))))
->setFilters(array('StringTrim', 'StringToLower'))
->addValidator('EmailAddress',false,array('messages' => array(
'emailAddressInvalid' => 'Please provide a valid email address.',
'emailAddressInvalidHostname' => 'Please provide a valid email address.'
)));

I searched through Zend_Validate_Abstract and some individual classes to see if any changes were made and couldn't find any (not the best way I know ).
I figured something must have been fixed for the 1.9.1 release that broke this feature. To be sure, I rolled back to version 1.8.2 and the above code
does work.

My development environment is as follows:
Windows XP Pro SP2
Apache 2.2
PHP 5.2.5

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Thomas Weidner added a comment -

"Does not work" is not enough information.
What is your input, and which errorkeys and messages are returned ?

Show
Thomas Weidner added a comment - "Does not work" is not enough information. What is your input, and which errorkeys and messages are returned ?
Hide
Permalink
David Joly added a comment -

Hi Thomas,

I examined the error keys being returned and they were the same as I have in my code snippet. The default messages were simply not being overridden with my custom messages.

Input: My typical testing input is anything that should cause a validation failure.

Error keys and message pairs:
'emailAddressInvalid' => "'%value%' is not a valid email address in the basic format local-part@hostname",
'emailAddressInvalidHostname' => "'%hostname%' is not a valid hostname for email address '%value%'",
'emailAddressInvalidMxRecord' => "'%hostname%' does not appear to have a valid MX record for the email address '%value%'"
'emailAddressDotAtom' => "'%localPart%' not matched against dot-atom format"
'emailAddressQuotedString' => "'%localPart%' not matched against quoted-string format"
'emailAddressInvalidLocalPart' => "'%localPart%' is not a valid local part for email address '%value%'"
'emailAddressLengthExceeded' => "'%value%' exceeds the allowed length"

I didn't try testing all of these (or any other validators for that matter). I just downloaded 1.9.1 a couple days ago and was working on my first form when the bug manifested itself. After spending an hour or so trying to figure out why the default messages were not being overridden I rolled back to 1.8.2 and everything works fine.

'emailAddressInvalid' was definitely returning the default message: "'test value' is not a valid email address in the basic format local-part@hostname"

I'll reinstall 1.9.1 and see if I can repeat the issue with other validators when I find the time.

Best Regards

Show
David Joly added a comment - Hi Thomas, I examined the error keys being returned and they were the same as I have in my code snippet. The default messages were simply not being overridden with my custom messages. Input: My typical testing input is anything that should cause a validation failure. Error keys and message pairs: 'emailAddressInvalid' => "'%value%' is not a valid email address in the basic format local-part@hostname", 'emailAddressInvalidHostname' => "'%hostname%' is not a valid hostname for email address '%value%'", 'emailAddressInvalidMxRecord' => "'%hostname%' does not appear to have a valid MX record for the email address '%value%'" 'emailAddressDotAtom' => "'%localPart%' not matched against dot-atom format" 'emailAddressQuotedString' => "'%localPart%' not matched against quoted-string format" 'emailAddressInvalidLocalPart' => "'%localPart%' is not a valid local part for email address '%value%'" 'emailAddressLengthExceeded' => "'%value%' exceeds the allowed length" I didn't try testing all of these (or any other validators for that matter). I just downloaded 1.9.1 a couple days ago and was working on my first form when the bug manifested itself. After spending an hour or so trying to figure out why the default messages were not being overridden I rolled back to 1.8.2 and everything works fine. 'emailAddressInvalid' was definitely returning the default message: "'test value' is not a valid email address in the basic format local-part@hostname" I'll reinstall 1.9.1 and see if I can repeat the issue with other validators when I find the time. Best Regards
Hide
Permalink
Thomas Weidner added a comment -

I need your Input, what you got as Failure Message, how you setup your custom messages and what you expected to get returned.

Unittests and own tests show no problem so I need more informations.

"Anything that causes a failure" is also tested by our Unittests... when this would be enough information I would have seen the error

Show
Thomas Weidner added a comment - I need your Input, what you got as Failure Message, how you setup your custom messages and what you expected to get returned. Unittests and own tests show no problem so I need more informations. "Anything that causes a failure" is also tested by our Unittests... when this would be enough information I would have seen the error
Hide
Permalink
David Joly added a comment -

Hi Thomas,

I am pleased to announce that I found the bug. It was in my head Sorry for waisting your time. I am not a professional programmer ATM and I am still very green with this stuff. I guess it's better that I make my mistakes now rather than later, right?

Again, I want to apologize for jumping the gun here. Also, I want to thank you and the rest of the Zend Framework contributors for all your patience and hard work to bring people like me such a fantastic code base to work with (and for putting up with false alarms).

Best regards,

David

Show
David Joly added a comment - Hi Thomas, I am pleased to announce that I found the bug. It was in my head Sorry for waisting your time. I am not a professional programmer ATM and I am still very green with this stuff. I guess it's better that I make my mistakes now rather than later, right? Again, I want to apologize for jumping the gun here. Also, I want to thank you and the rest of the Zend Framework contributors for all your patience and hard work to bring people like me such a fantastic code base to work with (and for putting up with false alarms). Best regards, David
Hide
Permalink
Thomas Weidner added a comment -

It's no problem for us.
That's why we are here.

Show
Thomas Weidner added a comment - It's no problem for us. That's why we are here.
Hide
Permalink
Daniel Masson added a comment -

David, ... can you plz post how did you get this solved ??, .. I'm having very similar issues, ...

thank you

Show
Daniel Masson added a comment - David, ... can you plz post how did you get this solved ??, .. I'm having very similar issues, ... thank you

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Zend Framework. Try JIRA - bug tracking software for your team.