Re: Re: Your opinion about QuickForm2 API
| From: | Brett Bieber | Date: | Mon, 16 Apr 2007 13:41:30 +0000 |
| Subject: | Re: Re: Your opinion about QuickForm2 API | ||
| References: | 1 2 | Groups: | php.pear.dev php.pear.general |
| Request: | Send a blank email to pear-dev+get-46240@lists.php.net to get a copy of this message | ||
On 4/16/07, Alexey Borzov <borz_off@cs.msu.su> wrote:
Hi, Bertrand Mansion wrote: We are in the middle of a discussion Alexey and I about QuickForm2 API for elements creation and I would like your opinion as well. At this point, nothing is immutable since we aren't even talking about alpha stage, so your preferences as users and developers is interesting. To summarize, Alexey would be in favor of this: $form->addElement('button', 'aButton', 'Click me please'); $form->addElement('select', 'aSelect', array('1' => 'option 1', '2' => 'option 2')); While I would be in favor of this: $form->addElement('button', 'aButton')->setContent('Click me please'); $form->addElement('select', 'aSelect')->setOptions(array('1' => 'option 1', '2' => 'option 2')); This is an example for adding a button to a form. The API can get more complex for Date elements and other javascript aided elements. I'd like to clarify a bit: both of the above calls are possible right now, see the relevant elements http://cvs.php.net/viewvc.cgi/pear/HTML_QuickForm2/QuickForm2/Element/Button.php?revision=1.1&view=markup http://cvs.php.net/viewvc.cgi/pear/HTML_QuickForm2/QuickForm2/Element/Select.php?revision=1.4&view=markup So this is just an issue of personal preference, which isn't being enforced or something. What's really being discussed is the following, will we make the "additional data" parameter that has different semantics from element to element always an array, so the first pair of calls above turns into $form->addElement('button', 'aButton', array('content' => 'Click me please')); $form->addElement('select', 'aSelect', array('options' => array('1' => 'option 1', '2' => 'option 2'))); even though the elements in question will never need any additional data other than 'content' and 'options'.'will we make the "additional data" parameter that has different semantics from element to element always an array,' +1 for this My vote would be for always an array --- even in cases where an element will only need one piece of scalar data. As many have already pointed out, changing from scalars to array based on the individual element leads to confusion about which elements require which parameter format --- I would even be against the flexibility of allowing both ways because I think it leads to more complicated documentation and more room for coding errors. -- -Brett Bieber http:saltybeagle.com aim:ianswerq