Re: QuickForm 3.0 news: renderers
| From: | Thomas Schulz | Date: | Thu, 13 Mar 2003 16:07:50 +0000 |
| Subject: | Re: QuickForm 3.0 news: renderers | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-14254@lists.php.net to get a copy of this message | ||
Alexey Borzov schrieb in php.pear.dev:
Hi Alexey,
> For the upcoming 3.0 release a new "Renderer" system was implemented.
good news :-)
> toArray() works through a new renderer as well, although its behaviour
> changed a bit: it does not return html for group elements, but rather
> an array of group elements' array representations. BTW, I need feedback
> from toArray() users: is this BC break OK with them or should I add a
> BC switch?
For me it's OK, because I wait for these behavior to have a cleaner way
to use toArray() with Smarty.
Some feedback after I get the current CVS-version and look at the
toArray()-output of QuickForm_example.php:
The special handling of "non-grouped" radio buttons looks not good for
me. How about numeric keys for all elements to avoid name conflicts?
...
[header] => Normal Elements
[elements] => Array
(
[0] => Array
(
[name] => ihidTest
[value] => hiddenField
[type] => hidden
...
)
...
[6] => Array
(
[name] => iradTest
[value] => 1
[type] => radio
...
)
[7] => Array
(
[name] => iradTest
[value] => 2
[type] => radio
...
)
...
The same for all elements inside a group-element:
[99] => Array
(
[name] => iradYesNo
[value] => Y
[type] => group
[frozen] =>
[label] => Yes/No:
[required] =>
[separator] => <<<-- would be nice to see here...
[elements] => Array
(
[0] => Array
(
[name] => iradYesNo[iradYesNo]
[value] => Y
[type] => radio
...
)
[1] => Array
(
[name] => iradYesNo[iradYesNo]
[value] => N
[type] => radio
...
)
)
)
All these would make it easyier to handle the array. What do you think?
Thomas.
--
http://4bconsult.de