On Mon, Aug 25, 2003 at 01:29:11PM -0700, Gisle Aas wrote:
> Mark Stosberg <[EMAIL PROTECTED]> writes:
>
> > > > Given the name of the selection list, I want to randomly select one of
> > > > the items in the selection list, and return the value that was selected.
> > > >
> > > > It sounds easy, but HTML::Form seems to be centered around the "OPTION"
> > > > tag, rather than the "SELECT" tag,
> > >
> > > Why do you have to care? The input-type name does not need to be
> > > exposed at all to do what you describe here. I just had to go with
> > > one name to make it into a "input-like" object and I went with OPTION.
> > > Perhaps I should just make SELECT and alias for the same thing.
> >
> > Thanks to Gisle's original post, I now have a test case below which
> > illustrates the issue I'm stuck on. The only difference is that
> > 'multiple="1"' has been added to the SELECT tag. Now 'possible_values'
> > returns (undef,1) instead of (1,2,3). I find this really confusing.
>
> What happens in this case is that you get 3 different option-inputs
> that can each have either the value undef or one of 1, 2 or 3
> respectively. It works just like multiple check-boxes that all have
> the same name.
Gisle,
Thank you for the prompt response. It was very helpful.
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.
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").
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.
The value() function would be still be useful for people that want that
kind of precision.
HTML::Form is being used more with the popularity of the easy-to-use
WWW::Mechanize user agent on the raise. While HTML::Form is already very
powerful and easy to use, this is the one point of the interface that
I've noticed feels awkward to work with.
What do you think?
Mark
--
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mark Stosberg Principal Developer
[EMAIL PROTECTED] Summersault, LLC
765-939-9301 ext 202 database driven websites
. . . . . http://www.summersault.com/ . . . . . . . .
