-- Simon Mundy <[EMAIL PROTECTED]> wrote
(on Sunday, 27 January 2008, 09:34 AM +1100):
> OK, using your sample form to illustrate my request:-
>
> $form->addElements(array(
> 'username' => 'text',
> 'password' => 'password',
> 'fullname' => 'text',
> 'email' => 'text',
> 'address' => 'text',
> 'postal' => 'text',
> 'submit' => 'submit',
> 'cancel' => 'submit'
> ))
> ->addDisplayGroup(array('username', 'password'), 'login')
> ->addDisplayGroup(array('fullname', 'email', 'address', 'postal'),
> 'demographics')
> ->addDisplayGroup(array('submit', 'cancel'), 'actions');
>
> Let's say instead you used instances of Zend_Form_Element instead of
> strings...
>
> $username = new Zend_Form_Element_Text('username');
> $password = new Zend_Form_Element_Password('password');
> $fullname = new Zend_Form_Element_Text('fullname');
> ... etc.
>
> You can't do this:-
>
> ->addDisplayGroup(array($username, $password), 'login')
>
> ...but I think there should be no difference - across the component you should
> be able to use either a string id of an element or the element itself when
> referring to methods that utilise one or more form elements. Similar to
> Zend_Acl...
>
> With regards to the addFormGroup functionality, I requested it simply because
> I
> can't see how you could ever sub-class a Form Group? It appears that it's
> hard-coded into the logic to add a display group. Allowing an
> 'addDisplayGroup'
> with an existing Zend_Form_DisplayGroup (or subclass) as the first method
> instead of an array would allow me to experiment with behaviours of the group
> and also free up the way I create forms.
I see two paths here, both of which should be done.
First, I'll add a couple of new settings to Zend_Form:
a defaultDisplayGroupClass property, as well as an option in the options
passed to addDisplayGroup(), displayGroupClass; these would allow you to
substitute your own DisplayGroup subclass to utilize. I'll start work on
that immediately.
The second, and harder task would be to do as you suggest: allow adding
concrete element instances to DisplayGroups, and then allow attaching
concrete display group instances to a form. There are some definite
issues with doing this, but nothing insurmountable. However, I consider
it low priority for the time being, as I think only a small percentage
of developers will need this sort of functionality, and the amount of
code required for it will be necessarily high (when attaching a group,
you'd then need to see if any elements match existing elements, and if
not, add them to the form; what to do about plugin loader inheritance
from the form to the display group; etc.)
> I can probably overcome these issues by having the display group have
> knowledge of its parent form, but will need to do some significant
> refactoring to do so.
>
> What is the use case for you? E.g., why do you want to instantiate
> display groups separately and add concrete elements to them instead of
> using addDisplayGroup and passing the element names? What problem does
> it solve? (Just gathering information here for the decision making
> process.)
>
>
> --
>
> Simon Mundy | Director | PEPTOLAB
>
> """ " "" """""" "" "" """"""" " "" """"" " """"" " """""" "" "
>
> 202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000
> Voice +61 (0) 3 9654 4324 | Mobile 0438 046 061 | Fax +61 (0) 3 9654 4124
> http://www.peptolab.com
>
--
Matthew Weier O'Phinney
PHP Developer | [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
