Ideas

Ideas on separate pages, to reduce clutter:

• Modularization
• Validation
• Streamlining the API for element values

;BINDINGS: Description forthcoming

;DELEGATION: Description forthcoming

The delegation pattern is described on Wikipedia. I have seen it being used a lot in the Cocoa framework, often to handle refresh of GUI elements, like tables for example. It is lighter than using a notification system but objects are more tightly coupled together.

In HTML_QuickForm2, Delegation can be used for datasource management.

$submitDatasource = new SubmitDatasource();
$form->setDatasource($submitDatasource);

Datasources are designed to feed the elements with their respective value(s). Ideally, there can be different datasources for a same element, for example one for its default value, one for its constant value, one for its submitted value, etc… Datasource can be almost any kind of object that conforms to a datasource interface.

;ELEMENT NAMES: No more element names computation. Groups purpose will only be to logically group elements, for organization and display purpose. Being in a group doesn't change the element name anymore (by adding brackets for example). In a way, it is like if $appendName is always set to false.

$element[] = new HTML_QuickForm_Element('el_type', 'name1', 'el_label');
$element[] = new HTML_QuickForm_Element('el_type', 'name[abc]', 'el_label');
$element[] = new HTML_QuickForm_Element('el_type', 'other_name', 'el_label');
$form->addGroup($element, 'group_name', 'group_label');

Don't quite get this part: why no name computation?

There are now HTML_QuickForm2_AbstractElement and HTML_QuickForm2_Element classes with streamlined API.

REMOVING CRUFT: Methods like setSize(), setMaxLength() for HTML_QuickForm_text and the similar methods containing only an updateAttributes() call should be removed. apiVersion() for element classes does not make particular sense, either.

;RADIOS: A radio group that works like a common select element, and accepts an array of options. This, instead of having to add a group to the form only to display radios.

$options = array('A' => 'Option A', 'B' => 'Option B');
$form->addElement('radios', 'radio_name', 'radios_label', $options);

Why not just use a single element “select” for all of those needs? Add a property “display” to it - and make it capable to render itself in a different way - depending on the “display” value. Examples:

• display=minimal: select is rendered as a dropdown box;
• display=full: select is rendered as a collection of radio-buttons or checkboxes (depending on whether “multiple” attribute is set to TRUE or FALSE);

I believe a single “select” element will be better for at least two reasons:

• It is logically more consistent (radio-buttons, checkboxes, dropdown boxes all represent the same logical entity - selection)
• It will be far less time-consuming to switch from one display type to another if we have a single element type.

;REPEAT: Adapt my repeat element to QF4.

HTML5 and Web Forms 2.0 are going to introduce new form elements : http://www.whatwg.org/specs/web-forms/current-work/

The registering and Factory functionality is moved to HTML_QuickForm2_Factory element, while basic functionality for adding elements is moved to HTML_QuickForm2_Container with DOM-like API. Container also implements the IteratorAggregate interface from PHP SPL allowing to easily traverse the elements.

It would be nice to move all presentation code (setRequiredNote(), getRequiredNote()) to renderers and validation-related code to some kind of validation object

It will also be nice to get rid of Backwards Compatibility cruft like process(), toHtml(), toArray()

Wouldn't it be nice to see more factory methods? Like addTextInput(), addTextarea() - for example? This would make the process of creating/appending elements cleaner. Of course, the general syntax - addElement() or appendElement() - should be kept, too, if we want custom elements to be available.

See a separate page for validation ideas

I am offering this type a functionality http://www.phpworkshops.com/demo for QuickForm 4. Two functions are used in javascript for the validation, they are respectively :
- validateUsingFunction(field, laFunction, parametre, ok, invalid)
- validateUsingRegExp(field, regex, parameter, ok, invalid)
Where field is a reference to the field objet, regex the regular expression, laFunction the function name, parametre is optional parameter passed to the function, ok is the string of text appearing when the entry is ok, and invalid is the error message.

You can find these functions in the library here: http://www.phpworkshops.com/demo/extended_library.js

I will post on time-tracking in a little while.

Ugh, looks like this stuff isn't online anymore…

For the JavaScript code itself, a class should be used instead of poluting the common namespace with function names.