Mark Stosberg <[EMAIL PROTECTED]> writes: > I would like to see an extension to this part of the interface which > allows one to treat single and multiple SELECT lists the same way. In > the current situation calling the same command can result in dealing > with either the SELECT tag, or the OPTION tag, which I find less useful > and confusing.
But it is a model that give a uniform behaviour and interface for all the inputs. I think this is a good thing and that it should be enough to write better documentation that explains the mapping between the HTML tags/elements and the HTML::Form input objects. As you discovered it is not one-to-one when it comes to <select>. > The current interface is very precise in the sense that it preserves the > ordering of the form widgets and allows me to toggle particular inputs > in a select tag by number. > > However, I find that I rarely care about the ordering of the OPTION tags > I'm reading or setting-- it just matters what the values are and how > many there are of each value. > > Maybe there could be a function "all_values", which always returns the > complete list of values (unlike "possible_values"). Since there is no representation of the <select> tag itself there is no object to put this method on. > Also functions could be added to make it easier to handle inputs with > multiple values. For me, I think the functions like CGI.pm's "param" and "append" > would be must intuitive. These functions would not care about ordering > like value() does, they would just set the first value that works. I can see this working. Regards, Gisle
