Re: [PEPr] Comment on HTML::HTML_QuickForm_Renderer_Tableless

Mark Wiesemann wrote: >> One tricky question, how does the fieldset implementation handles >> multiple headers in one form...? > > I wasn't really aware of the fact that QF allow multiple header > elements, therefore I've added no special handling for multiple headers. > > Currently it would be rendered like this (three header elements): > http://www.markwiesemann.de/php/Tableless/contact.php > > Ideas for better handling of multiple headers are welcome. > > Another thing: Via PM I got another idea for this new renderer: The > possibility to have multiple fieldsets. The suggestion was to add a > method addFieldset() to the renderer that expects an array of element > names. > > Maybe it would be better to extend QF itself with this such a method. > This could then be combined in a new package > ("HTML_QuickForm_Tableless") with three components: > - Tableless renderer > - DHTMLRules for those tableless forms (as in my example 2) > - multiple fieldsets > > There would then be a class HTML_QuickForm_Tableless which extends > HTML_QuickForm class and adds the following: > - Tableless renderer as default renderer > (which allows then to use $form->display() instead of the current > code with $renderer = ...; $renderer->accept(); renderer->toHtml();) > - addFieldset($name, $elements, $attrs) method > > $name would be for internal usage and $elements would be an array of > element names. If one of them is a header element, it could be used as > the legend of this new fieldset. All elements that don't belong to a > fieldset that was added via addFieldset() will get into a default > fieldset (as it is now). > > This extended QF class could also decline multiple header elements for > a single fieldset (i.e. throw back an PEAR error), but maybe somebody > of you has a good idea for handling of multiple headers. > > Comments on this are welcome, either here or via private mail! > > Thanks, > Mark I think the best way to handle that would be to create a fieldset for each header. This way the API is really basically the same as with the current default renderer. Start with a default fieldset, if first field is a header put it as legend, then add fields, and when you hit a new header, close the previous fieldset and start a new one. You wouldn't need the "addFieldSet()" method which would break if you were to switch renderer. -Philippe