IANK, but try
<select oid="userList">
<option oid="ufile">
</select>
<?
userList {
item = ufile
list = create_user_list
}
?>
Yup. Just about to post as well.
Thanks, David.[/QUOTE]
David got it. Think of it this way:
A select list is a two part widget. You have the select box, which requires
a repeated list of options, and then you have each of the options.
If you do your first form:
<select oid="userList">
<option>@ufile</option>
</select>
Then the list will look right, but Iowa won't know which object was actually
selected in the select box. Now, on the surface that seems confusing, but
consider this. What if ufile were, instead of a string, a struct or some
other object that had, say, a name() method/reader. So you could do this:
<select oid="userList">
<option>@ufile.name</option>
</select>
You will see the names in the select box, but Iowa has no way of equating
those names with the object they came from. However, if you do this:
<select oid="userList">
<option oid="ufile.name"/>
</select>
Then Iowa can say, "By Jove! That <option> tag is dynamic! When it is
selected, I need to return whatever @ufile was for that tag."
I use this all of the time in instances where I have performed a database
query, putting the rows into an array of objects. From the user
perspective, they are simply going to select one or more options from a
select box, but at the code level, they are really selecting rows with all
of the data items that go with them.
Chemical Name: <select oid="chemical_list">
<option oid="chemical.chemical_name"/>
</select>
When the code gets the selection, it gets the full object, not just the
name. Because of this (this example assumes Kansas object/relational
mapping syntax), if I want to actually get a list of all of the schools that
have that chemical for a new page where they are going to select a school,
all I have to do is:
@school_list = @chemical.schools
And that is very, very nice.
Make sense?
Thanks for the question,
Kirk
