Issue Type: Task Created: 2010-03-06T17:17:01.000+0000 Last Updated: 2012-11-20T21:37:34.000+0000 Status: Open Fix version(s): Reporter: Christian Albrecht (alab) Assignee: None Tags: - Zend_Form
Related issues: Attachments:
Reorganizing and cleaning SubTasks now.
Posted by Christian Albrecht (alab) on 2010-03-06T17:34:26.000+0000
This is a Fix for the whole Zend_Form package.
Posted by Christian Albrecht (alab) on 2010-03-06T19:22:00.000+0000
To Matthew Weier O'Phinney @ ZF-6062
Overloading actually works with variables with numeric values, i have a deeply nested setup working with numerical form names.
Posted by Kai Uwe (kaiuwe) on 2010-03-07T03:43:17.000+0000
Notice for XHTML: ID and NAME must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").
Look here: [http://www.w3.org/TR/2000/REC-xml-20001006#id] [http://www.w3.org/TR/2000/REC-xml-20001006#NT-Name]
Posted by Christian Albrecht (alab) on 2010-03-07T16:24:17.000+0000
Cleaned the patch, found the truly bug within isValid() and isValidPartial() which causes loss of data with SubForms and ElementsBelongTo.
<pre class="highlight">
public function isValid|isValidPartial
{
...
// This handles BelongsTo and returns in all cases, even without
// belongsTo Array Notation the data for the current (Sub)Form
$data = $this->_dissolveArrayValue($data, this->getElementsBelongTo());
...
// Here is the bug which eats SubForm data when descending deeper
// into $data as this is already done by dissolveArrayValue and will
// be done in the next cycle as well
if (isset($data[$key])) {
$valid = $form->isValid($data[$key]) && $valid;
}
...
}
Posted by Kai Uwe (kaiuwe) on 2010-03-09T10:41:08.000+0000
This is a bad idea: ??Invalid name provided; must be unique per (Sub)Form??
Example:
<pre class="highlight">
Old price:
New price:
Or
<pre class="highlight">
Posted by Christian Albrecht (alab) on 2010-03-09T10:55:31.000+0000
Kai Uwe the current implementation as found in the source of Zend Framework 1.10.2 simply overwrites your equal named submit buttons without notice.
you do
$form = new Zend_Form(); $form->addElement('submit','Submit',array('options'=>array('value'=>'red'))); $form->addElement('submit','Submit',array('options'=>array('value'=>'green'))); $form->render();
As result you will get a value="green" submit button, but no red one.
And if its not the correct syntax - hey, it's just an example.
Posted by Kai Uwe (kaiuwe) on 2010-03-09T11:32:22.000+0000
Hi Christian, I know the bug in the current version, but your patch also doesn't solve the problem. Another idea: I think the Zend_Form class is not the right place. This part is better for decorators (Callback, ViewHelper, ViewScript) and/or the view.
Posted by Sergio Medina (sergiomedinag) on 2010-03-09T14:34:00.000+0000
Hi Christian. How can I apply this new fix?
Posted by Christian Albrecht (alab) on 2010-03-09T15:31:21.000+0000
Hey Sergio on linux console this is done with the patch command. But please be aware that this issue is not even commented yet by core developers.
Posted by Christian Albrecht (alab) on 2010-03-11T05:08:50.000+0000
Refactoring patches and Structure of issue.
Posted by Christian Albrecht (alab) on 2010-04-05T06:12:42.000+0000
Added a patch so changing Type.
Posted by Christian Albrecht (alab) on 2010-04-05T06:13:19.000+0000
That was the wrong issue ;P
Posted by Christian Albrecht (alab) on 2010-04-20T09:31:08.000+0000
Changing Priority since the 'loss of data Issues' are resolved.