ZF-9364: Zend_Form isValid|isValidPartial overwrites Translator of SubForms and Elements
Description
Zend_Form isValid and isValidPartial calls $element->setTranslator() not respecting if an individual Translator was set for $element.
Zend_Form isValid and isValidPartial calls $element->setTranslator() not respecting if an individual Translator was set for $element.
Comments
Posted by Dominique Lorre (dlorre) on 2010-03-23T08:39:30.000+0000
That would be better fixed in the isValid() method of Zend_Form_Element which is overriding the translator for validators. Hence, it would allow us to use the resources/translators arrays and our custom translator for the elements.
line 1330 in Zend_Form_Element:
[code] foreach ($this->getValidators() as $key => $validator) { if (method_exists($validator, 'setTranslator')) { $validator->setTranslator($this->getTranslator()); } [/code]
Posted by Christian Albrecht (alab) on 2010-03-23T10:23:19.000+0000
Dominique, you are right that the Validation translator is overwritten in Zend_Form_Element::isValid(), but that really is a different issue.
But i realized now the example above is not at the state of the patch, i will update that.
Posted by Rob Allen (rob) on 2010-03-23T13:46:20.000+0000
The description isn't too helpful :)
The actual problem reported here is that if you attach a translator object to the form and to one of the elements, then the translator object attached to the element is overridden by the one attached to the form when isValid() or isValidPartial() is called. It is reasonable that the law of specificity applies here and that if someone has taken the trouble to apply a translator to the element, then it should be used in preference to the form level one.
Correct patch:
Posted by Rob Allen (rob) on 2010-03-23T14:19:40.000+0000
Fixed in trunk r21617 and release-1.10 branch r21618.
Posted by Christian Albrecht (alab) on 2010-03-24T00:23:45.000+0000
Thank you Rob, as i am new to ZFdev and new to collaborative OS Development in general, i am not used to the terms. You have correctly described the problem i thought to address here.
I only recognize Zend_Form growed over time, getting more features and loosing concept.
Posted by Dominique Lorre (dlorre) on 2010-03-24T04:06:14.000+0000
Christian, I was referring to ZF 9275 which is mentioned to be fixed by this patch.
Posted by Christian Albrecht (alab) on 2010-03-24T07:31:08.000+0000
Dominique, i reopend [ZF-9275]
Posted by Christian Albrecht (alab) on 2010-03-25T08:16:02.000+0000
The commited fix is incorrect as $element->getTranslator() will return the default Translator from Zend_Form and if Zend_Form has no default Translator set the one from Zend_Registry if this is set. Only when there is no translator set in the chain $element->getTranslator() returns null.
So in a case when there is an indivdual Translator set for Zend_Form which should overwrite the default Translator from Zend_Form or even Zend_Registry this will not happen.
Cleaner solution, add Method hasTranslator() to Zend_Form and Zend_Form_Element
Posted by Christian Albrecht (alab) on 2010-03-25T08:17:18.000+0000
Please review, there is an error in the commited fix.
Posted by Christian Albrecht (alab) on 2010-03-25T08:38:11.000+0000
proove that it works
Posted by Rob Allen (rob) on 2010-03-25T14:45:00.000+0000
The commit works as designed to fix the described issue :)
There is however a new issue introduced as a result as noted by Christian: If the element doesn't have a local translator and a translator is set into the registry using the key "Zend_Translate", then the form's translator is not used and the one in the registry is used instead.
As noted, this is because Zend_Form_Element::getTranslator() will return the 'Zend_Translate' translator if there isn't a local one set.
This patch with unit test fixes it:
Posted by Rob Allen (rob) on 2010-03-25T14:49:26.000+0000
Fixed again. Trunk: r21648, release-1.0 branch: r21649