Matthew Weier O'Phinney schreef:
-- Bart McLeod <[EMAIL PROTECTED]> wrote
(on Wednesday, 27 August 2008, 05:32 PM +0200):
I think I found a clue. The select elements seem to have gotten an in_array
validator! it does never validate, since the options aren't added until very
late, because lesser options are added as more of them are already in use.
So this validator, however nice, has killed my subform processing. I can
probably remove the validator or do not check and just populate the subform,
since I am not checking it anyway. Or add all of the options, just for
validations sake, which will be the best option I guess.
So, problem solved, beware!
You can also disable loading this validator:
$element->setRegisterInArrayValidator(false);
// Or, pass a boolean false value to the 'registerInArrayValidator'
// option when instantiating.
BTW, this validator is added by default for all elements deriving from the
Multi base class -- which includes Select, Multiselect, MultiCheckbox,
and Radio. The idea was to make it simpler to register these --
typically you'll use the inArray validator with the exact same options
you pass in.
I like the idea. It is actually quite good. I just hoped to save on
performance by not adding all the options for all of the subforms from
the start, since most of them won't be used anyway, but I think the
benefit of automatic validation outweighs the benefit of a little extra
performance. I will be in need of an opcode cache anyway. I could also
inverse the approach and use a hidden element a the start and only
replace it with a select if one is really being used. For now, I hapily
take the benefit of the automatic white list validation.
Regards,
Bart McLeod
Bart McLeod schreef:
I printed the results of validation to the screen and I get this remarkable
outcome:
save : opslaan - valid
delete : - valid
code : bedrijfsinfo - valid
sequence_number : 10 - valid
in_mainmenu : 1 - valid
begin : 27-08-2008 - valid
end : 31-12-9999 - valid
number_of_childbranches : 1 - valid
number_of_parentbranches : 1 - valid
number_of_translations : 1 - valid
translation : bedrijfsinfooooooooooooooooooo - valid
language_id : DEU - valid
remove : - valid
branch_id : - valid
subcode : - valid
sub_sequence_number : 1 - valid
remove : - valid
branch_id : - valid
maincode : - valid
sub_sequence_number : 1 - valid
remove : - valid
translation : bedrijfsinfooooooooooooooooooo - valid
language_id : DEU - INVALID
remove : - INVALID
The last time a subform is checked, it is invalid, while with the same
values, it is valid if checked in the form as a whole. Something very
strange is happening.
I will try removing the validation check for now.
Bart
Bart McLeod schreef:
* Fixes to how array notation with subforms works. This _may_ affect
what you're observing; if so, it's likely you were working around the
issues, and I may be able to present a fix.
This is likely to be the cause of the problem! So far I found the form
validates with $_POST as is, BUT it does not get populated with the
correct values.
This is the form:
class SubFormTranslation extends CmsSubForm {
public function init(){
parent::init();
//translation field
$translation = new Zend_Form_Element_Text('translation');
$translation->setLabel('translation')->setAttrib('class',
'_450');
$this->addElement($translation);
//language_id field
$language_id = new Zend_Form_Element_Select('language_id');
$language_id->setLabel('language');
/*I do not set required here becuase it complicates
reducing the options
* upon reload the validator will mourn if a language_id is
absent
* while it is nothing to worry about
* */
$this->addElement($language_id);
parent::postInit();
}
public function render(Zend_View_Interface $view = null){
if($lang = $this->language_id->getValue()){
$decorator = new ReadOnlyDecorator();
$decorator->setDisplayValue(Globals::getDago()->
getLanguageName($lang));
$this->language_id->addDecorator(array('div' =>
$decorator));
}
$this->setRemovalScript(__CLASS__);
return parent::render($view);
}
}
The elements that get added in init are the only two elements, except
for a removal button that is added in the ancestor CmsSubForm.
Nothing is required, yet it does not validate if given an array. Should
the array have the indexes in the format: formname-fieldname? I am
currently feeding them as fielname.
Sample data:
language_id: de
translation: something
Sample post data:
array('subform_translation1' => array('language_id' => 'de',
'translation' => 'something'));
Expected outcome:
true === $subform->isValid($sample_post_data['subform_translation1']);
Real life outcome:
false === $subform->isValid($sample_post_data['subform_translation1']);
Hope this helps you in finding the answer that I am overlooking!
Regards,
Bart McLeod
Matthew Weier O'Phinney schreef:
-- Bart McLeod <[EMAIL PROTECTED]> wrote
(on Wednesday, 27 August 2008, 03:36 PM +0200):
To be more specific:
if($subform->isValid($_POST[$formname])){
if($this->validateSubform($subform, $code,
'processTranslation')){
$changed = true;
}
}else{
//this part should not be needed
echo "subform is invalid.". print_r($_POST,
true);
}
The subform does not validate. The version that is in
production does.
With a version of ZF standard/trunk that is about six weeks
older than
my current version.
Anyone?
Can you send me the form and some sample data to try and validate?
Hard
to know what changed, and I'd like to find out.
There were two primary changes to forms for 1.5.3 and 1.6.0:
* Implemented lazy-loading of plugins. This shouldn't affect what
you're observing, however.
* Fixes to how array notation with subforms works. This _may_
affect
what you're observing; if so, it's likely you were working
around the
issues, and I may be able to present a fix.
Bart McLeod schreef:
Hi all,
I have been on a long vacation. So after six weeks I have
updated my
ZF library from svn, and guess what: subforms processing in
my
application is broken now. Anyone knows of any changed
functionality:
naming of elements for example? Because the number of
subforms is
dynamic, I have to check for their names in $_POST to see
if there are
any to process.
There are no errors whatsoever, they just don't get
processed.
Regards,
Bart McLeod
