- From: Olav Junker Kjær <olav@olav.dk>
- Date: Mon, 09 Aug 2004 18:38:18 +0200
I would like to get rid of the "index" attribute on fields in xml formdata. I think it binds the server side processing too tightly to the UI, by relying on the document order of controls. If I understand correctly, the role of the index is for identifying controls in the case where controls cannot be identified only by name (and perhaps value). E.g. when several text field in the same form has the same name. I think it is a reasonable trade-off, to require that fields (apart from check boxes and radio buttons) should be uniquely named (in the form scope), and that values should be unique for check boxes and radio buttons with the same name, and for options in a select. The pay-off would be that form processing is separated from the layout of the form. The order of the controls can be changed, a radio group can be changed into a select, a checkbox group can be changed into a select multiple (and vice-versa) without modifying the server processing. Also, we could have different UI's to the same processing script, or differently designed forms could be prefilled from the same UI-neutral data source. Duplicate names shouldn't be banned, but in the case of xml formdata submission, replace=data, or prefilling via the "data" attribute on forms, behavior should be undefined when controls names are not unique. (Or it could be defined that if several controls share the same name, only the first (in document order) would be filled. It would not be very useful to have duplicate names then, but it wouldn't be an error either.) Its not a big deal to add the index when xml-encoding form data, it's more the other way around, when fetching formdata from the server, that I think "index" shouldn't be required. But I like the symmetry between the two formats. Have I missed an obvious use-case for "index"? Olav Junker Kj?r
Received on Monday, 9 August 2004 09:38:18 UTC