Zend Framework

Zend_Filter_Input does not always return all error messages from getMessages

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: 1.5.2
  • Fix Version/s: 1.10.0
  • Component/s: Zend_Filter_Input
  • Labels:
    None

Description

Using the array of validators below, only one of the three regex error messages is ever returned from getMessages().

$aValidators = array(
'password_new' => array(
array('StringLength', 8),
new Zend_Validate_Regex('/[0-9]+/'),
new Zend_Validate_Regex('/[A-Z]+/'),
new Zend_Validate_Regex('/[a-z]+/'),
'presence' => 'required',
'allowEmpty' => false,
'messages' => array(
'Password must contain 8 or more characters',
'Password must contain at least one number',
'Password must contain at least one capital letter',
'Password must contain at least one lower case letter'
)
)

The 8 character limit check always works correctly.
If the password 'aa' is submitted the the 'at least one capital' message is returned. If the password 'AA' is submitted then the 'at least one lower case letter' message is returned. If 'Aa' is used the the 'at least one number' message is returned. In ZF1.04 the correct behaviour is seen - 'AA' and 'aa' return two errors each and 'Aa' returns just the 'at least one number' message.

Issue Links

This issue is duplicated by:
ZF-6764 Minor misconception in Zend_Validate messages processing Major Resolved

Activity

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

Fixed component assignment

Show
Thomas Weidner added a comment - Fixed component assignment
Hide
Permalink
Thomas Weidner added a comment -

The reason for using the messageKeys from the validator is that this enables us to translate them.

We have the following possibilities in my opinion:
*) First validator returns messageKey, when more than one of the same validators are used then every additional validator can return a numerical key which would mean that the previous one is not overwritten.

BUT: This could mean that we are no longer be able to translate as most users use the messageKey of the validator for translation and not the message itself (which is often not possible as values are included)

*) We could change behaviour to return an array instead of a string when more than one message is returned.

BUT: This is very problematic as it would break an userland code, and makes things much more complicated in other components... I would not to this.

*) We could concate the messages and seperate them with a special sign ( "message1|message2"). This would not break BC but does not look good.

*) We could close this issue as won't fix and clearify this within the manual.

Show
Thomas Weidner added a comment - The reason for using the messageKeys from the validator is that this enables us to translate them. We have the following possibilities in my opinion: *) First validator returns messageKey, when more than one of the same validators are used then every additional validator can return a numerical key which would mean that the previous one is not overwritten. BUT: This could mean that we are no longer be able to translate as most users use the messageKey of the validator for translation and not the message itself (which is often not possible as values are included) *) We could change behaviour to return an array instead of a string when more than one message is returned. BUT: This is very problematic as it would break an userland code, and makes things much more complicated in other components... I would not to this. *) We could concate the messages and seperate them with a special sign ( "message1|message2"). This would not break BC but does not look good. *) We could close this issue as won't fix and clearify this within the manual.
Hide
Permalink
Thomas Weidner added a comment -

Closing as won't fix.

Actually solution 4 is alreaddy available.
A integration would eighter break the possibility of I18n (numeric keys) or add a BC problem (multidim array).

Show
Thomas Weidner added a comment - Closing as won't fix. Actually solution 4 is alreaddy available. A integration would eighter break the possibility of I18n (numeric keys) or add a BC problem (multidim array).

People

Vote (0)
Watch (1)

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.