Implementation Issues

There are two possible implementations for these methods:

This effectively means that we just iterate over all children of the element and check whether child's id (or name) attribute is equal to the given one

Advantages:

• Very simple

Disadvantages:

• O(N)

This means that on adding the Element to the Container we create a mapping of its id (or name) attribute to its actual index. When using the get*() methods we can just directly grab the needed elements.

Advantages:

• O(1)

Disadvantages:

• Complex code on adding and removing elements
• Cache should be updated when id or name attribute changes

It should be decided whether we should allow the elements with duplicate IDs into form. If they are allowed, we should also decide how we should handle the getElementById('duplicate-id') call.

Some thoughts from Mark Wiesemann about the rendering part of QF2:

• Templates:
  • The “language” of QF's default renderer got rather complex in the table, and I had a lot of people that complained about this complexity that makes it hard to understand and to modify the tableless template to the needs of the users. What is “language” in this context?
    • “Language” is the way how the templates are defined, i.e. the combination of HTMLanguage, curly braces and “comments” for blocks. While the concept is easy to understand, I guess that it is rather confusing to see the rather long element template in QF's default renderer or in my tableless renderer for QF. Maybe just some (real) linebreaks could make them more readable.
  • My current usage of this templates is also not perfect, e.g. are the (multiple) fieldset templates not consistent to the (single) form template, and the closing fieldset template closes more than what the opening fieldset template has opened (there is an additional </ol>).
  • Another problem is the need of two template blocks for a reasonable DHTML validation: There needs to be a template block that allows to assign an additional style (CSS), and there needs to be a second block for the error message. While this is reasonable, it makes the element template rather hard to understand and long.
  • I hadn't had a good idea on this could be improved yet, but IMHO this needs to be improved. It also should be more clear how the templates can be changed. I had a lot of questions about this from various people. The usual ideas here are to write more docs and examples ;)
• Layout:
  • The old QF default layout for forms was useful, but kind of old and not really compatible to fieldsets and nesting of fieldsets. QF2's default layout shouldn't follow QF here, but provide a usual fieldset layout, similar to the currently bundled examples. (These examples need to checked on various browsers because they are based on older tableless renderer styles which might have gotten some corrections.)
• IDs and labels:
  • The problem of missing IDs has already gone in QF2, and elements get already <label> tags (together with “for” attribute references to the IDs) assigned in the examples. But it needs to be discussed how this should work for groups. The tableless renderer's behaviour of assigning the “for” attribute to the first element of the group (e.g. the hour select box in a “H:i” time field) could be seen as a hack.
• Hidden elements:
  • The tableless renderer currently puts hidden elements into a fieldset with a special CSS class. This is something a lot of people wondered and/or complained about. The decision was made for XHTML validity reasons (i.e. <form> must not contain <input>, while <fieldset> may contain <input>). XHTML validity should still be given in QF2 but the elements should maybe be better in <div> (e.g. in a <div style=“display: none;”> as in the currently bundled example). Current Default renderer just wraps the whole table in <div></div>, examples for QF2 wrap each hidden element in <div style=“display: none;”></div>, I think any approach is possible. NB: In my own usage of QuickForm I hit a situation where I needed hidden elements to be rendered exactly where I put them (i.e. within the limits of the group) so we should consider this as well.
    • Comment to the last point: The renderer could have a switch: By default, the hidden elements could be output in the current way (all together). The alternative setting would be to output the hidden elements at the defined point (in order of the addElement() or whatever calls) with the usual element template.
• DHTML/JS validation:
  • This should be rewritten from scratch IMHO. Justin Patrin needed to use several hacks to get DHTML validation to work, and I have added even more hacks to make this work with the tableless renderer and to remove several bugs that Justin's code had with groups.
  • Easier distinction between real groups and element names that indicated in QF that they were a group (because of square brackets) would be very helpful to make the new code easier to maintain.
  • A OO interface would be nice. There could be general validation class with special classes for the old alert() error messages and for the newer DHTML error messages, so that people could decide which style they like more. (And this would avoid code duplication or hacking one solution into the other.) Yeah, we should have some base library that can be put into a separate .js file rather than build validation code for each form from scratch

I'd also like to see your ideas on actual API for HTML_QuickForm2_Renderer class. — Alexey Borzov 2007-12-09 22:09