-- Matthew Weier O'Phinney <[EMAIL PROTECTED]> wrote
(on Monday, 11 February 2008, 12:53 PM -0500):
> -- 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.
This part is now in current trunk.
> 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.)
--
Matthew Weier O'Phinney
PHP Developer | [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
