Hi all--we're putting the final touches on the 1.8 beta but I ran into
some aspects of the new Radio Group form tag on which I'd like to get
some feedback.

The radio group form tag will allow you to easily add a group of radio
buttons to your view pages by importing the form custom tags:
<cfimport prefix="form" taglib="/MachII/customtags/form" />

And then calling the radiogroup tag:
<form:radiogroup name="myRadioGroup" ...>

Unlike a lot of the other tags we've already implemented, however, there
are a lot of ins and outs with the radiogroup tag so rather than just
implement it, I'd like to get everyone's feedback on how they'd like to
see it work.

LAYOUT
======
The radiogroup tag will involve both labels and values, which of course
immediately gets into layout issues. We'd like to let you specify a
layout as well as provide simple defaults for when you don't need as
much control over things.

xFor default layouts, do these options make sense?

If a layout is not provided in the body of the tag (more on that in a
moment), a default layout will be created and any applicable CSS would
apply for styling the radio buttons and text.

If no layout direction is provided, e.g.:
<form:radiogroup name="foo" labels="Fee,Fi,Fo,Fum" values="1,2,3,4" />

Should we assume horizontal or vertical layout? Horizontal being (with *
representing the radio button):
* Fee * Fi * Fo * Fum

Vertical being:
* Fee
* Fi
* Fo
* Fum

Also, I'm assuming people will always want the radio button BEFORE the
label, but would people need control over that as well?

If you want to do something other than the default layout direction but
still not get fancier than that, does layoutDirection make sense as an
attribute?
<form:radiogroup name="foo" labels="Fee,Fi,Fo,Fum" values="1,2,3,4"
layoutDirection="vertical" />

On vertical we'd use <br /> tags between the elements. Horizontal would
simply be a space between elements.

Now if you want to be more explicit by using other HTML tags in your
layout, you'd provide a body to the tag:
<form:radiogroup name="foo" labels="Fee,Fi,Fo,Fum" values="1,2,3,4">
STUFF HERE
</form:radiogroup>

As for how the STUFF HERE bit works, there are some options. The first
one we discussed was modeling it after the Grails radiogroup tag, which
uses data-binding style notation to indicate where the labels and
buttons should go. So this:
<form:radiogroup name="foo" labels="Fee,Fi,Fo,Fum" values="1,2,3,4">
<li>${radio} ${label}</li>
</form:radiogroup>

Would result in the following HTML:
<li><input type="radio" name="foo" value="1" /> Fee</li>
<li><input type="radio" name="foo" value="2" /> Fi</li>
<li><input type="radio" name="foo" value="3" /> Fo</li>
<li><input type="radio" name="foo" value="4" /> Fum</li>

Does that syntax make sense, and do people like it?

LABELS AND VALUES
==================
I'm planning on allowing the following to be used for labels and values:
1. explicit lists (default comma-delimited, but a delimiter can be provided)
2. structs
3. arrays
4. queries

Explicit lists are in the examples I provided above, but of course they
could be a variable so long as the variable used is a list. If something
other than a comma is used for the delimiter, it would be passed as an
attribute of the tag.

When explicit lists are used, both values and labels must be provided.
Or do people see a need to be able to provide values without providing
labels? Didn't make sense to me but figured I better ask since there
might be a valid use case I'm just not coming up with.

With all the other data types, there are multiple options. These are
proposals--feel free to comment on ANY of this behavior.

Also an overall question: do people want to have the ability to use one
datatype for values and another for labels, or is requiring the same for
both (when both values and labels are provided) OK?

STRUCTS:
* If values is a struct and labels is not provided, the struct key will
be used as the value, and the struct value will be used as the label
* If values is a struct and labels is provided, the struct key will be
used as the value
* If labels is a struct and values is not provided, see the first bullet
above (not sure we really need this option)
* If labels is a struct and values is provided, the struct value will be
used as the label

ARRAYS:
* if values is a one-dimensional array, labels is required
* if labels is a one-dimensional array, values is required
* if values is a two-dimensional array and labels is not provided, index
one of each array element will be used as the value, and index 2 of each
array element will be used as the label
* if labels is a two-dimensional array and values is not provided,
behavior will be the same as above
* if values is a two-dimensional array and labels is provided, index 1
of each array element will be used as the value
* if labels is a two-dimensional array and values is provided, index 2
of each array element will be used as the label
* arrays with more than two dimensions are not supported

QUERIES:
* if a query is used for values, the valueQueryColumn attribute is required
* if a query is used for labels, the labelQueryColumn attribute is required
* if a query is used for values and labels is not provided, both
valueQueryColumn and labelQueryColumn attributes are required
* if a query is used for labels and values is not provided, the behavior
would be the same as above
* a different query may be used for values and labels, but
valueQueryColumn and labelQueryColumn are both required in this case

I think that covers what I've been thinking through thus far--your
feedback, thoughts, and questions are GREATLY appreciated.

Thanks,
Matt
--
Matt Woodward
m...@mattwoodward.com
http://www.mattwoodward.com/blog

Please do not send me proprietary file formats such as Word, PowerPoint,
etc. as attachments.
http://www.gnu.org/philosophy/no-word-attachments.html

smime.p7s 4K Download

Pretty interesting stuff coming down the pipe here!

I have a few comments about the (X)HTML generated by this tag from the
layout/formatting perspective.

* I vote for the default layout to be vertical. Seems like most radio
lists out in the wild are such.

* It is proper to use <label> tags around all field labels. Doing this
helps semantically associate the labels with the fields, makes styling
with CSS easier, AND let's you click on the label text to select the
radio button.

* Using <br/> tags to make a series of non-styled <inputs> into a
vertical list can cause trouble when wanting to apply styling to them.
Would prefer to just rely on the <label> and <input> and format them w/
CSS or if absolutely necessary use a list style tag like <li> to wrap
each option.

Thanks!
.jonah

On Jun 15, 3:31 pm, Matthew Woodward <m...@mattwoodward.com> wrote:

Comments inline below.  Good stuff Jonah.

.jonah said the following on 06/15/2009 10:06 PM:

I'm wondering if we should have a "default layout".  However, I guess
the default should be with <p>'s.  I'm wondering if should build
something (like HTML helper) for people to define layouts for it and
then reference <form:radioGroup layoutName="coolVerticalList" ... />
Yeah, I agree that using <label> is a good thing.  But, I sorta see if
as part as layout.
I'm wondering if it would be better idea to not having default layouts.  
If we use <li>, people have to put <ul>'s around it.

<ul>
  <form:radiogroup name="foo" labels="Fee,Fi,Fo,Fum" values="1,2,3,4">
  <li><label for="${attribute.id}">${radio} ${label}</label></li>
  </form:radiogroup>
</ul>

I think we'll have to add additional functionality to get at attributes
like getting the "id" for a label.

<<Also, I'm assuming people will always want the radio button BEFORE the
label, but would people need control over that as well?>>  Yes, I like
to put the label BEFORE the button.

<<If you want to do something other than the default layout direction
but still not get fancier than that, does layoutDirection make sense as
an attribute?>> Yes, sounds good.

<<So this:
<form:radiogroup name="foo" labels="Fee,Fi,Fo,Fum" values="1,2,3,4">
<li>${radio} ${label}</li>
</form:radiogroup>

Would result in the following HTML:
<li><input type="radio" name="foo" value="1" /> Fee</li>
<li><input type="radio" name="foo" value="2" /> Fi</li>
<li><input type="radio" name="foo" value="3" /> Fo</li>
<li><input type="radio" name="foo" value="4" /> Fum</li>

Does that syntax make sense, and do people like it?>>  Yes.

<<Or do people see a need to be able to provide values without providing
labels?>> I always label my radio buttons.

<<Also an overall question: do people want to have the ability to use
one datatype for values and another for labels, or is requiring the same
for both (when both values and labels are provided) OK?>>  One datatype
will work for me.

Thanks Matt!

ed

______________________________________________________________________
Ed Szwedo
Web Development Team Lead
CSC

109 TW Alexander Drive, Building NCC, Mail Drop N176-05, Research
Triangle Park, NC 27711
Information Technology Infrastructure Solutions | Office: (919)541-3955
| Fax: (919)541-3641 | szwedo...@epa.gov | www.csc.com

  From:       Matthew Woodward <m...@mattwoodward.com>                                                                

  To:         mach-ii-for-coldfusion@googlegroups.com                                                                  

  Date:       06/15/2009 06:32 PM                                                                                      

  Subject:    [Mach-II] Feedback Wanted: Radio Group Form Tag                                                          

Hi all--we're putting the final touches on the 1.8 beta but I ran into
some aspects of the new Radio Group form tag on which I'd like to get
some feedback.

The radio group form tag will allow you to easily add a group of radio
buttons to your view pages by importing the form custom tags:
<cfimport prefix="form" taglib="/MachII/customtags/form" />

And then calling the radiogroup tag:
<form:radiogroup name="myRadioGroup" ...>

Unlike a lot of the other tags we've already implemented, however, there

are a lot of ins and outs with the radiogroup tag so rather than just
implement it, I'd like to get everyone's feedback on how they'd like to
see it work.

LAYOUT
======
The radiogroup tag will involve both labels and values, which of course
immediately gets into layout issues. We'd like to let you specify a
layout as well as provide simple defaults for when you don't need as
much control over things.

xFor default layouts, do these options make sense?

If a layout is not provided in the body of the tag (more on that in a
moment), a default layout will be created and any applicable CSS would
apply for styling the radio buttons and text.

If no layout direction is provided, e.g.:
<form:radiogroup name="foo" labels="Fee,Fi,Fo,Fum" values="1,2,3,4" />

Should we assume horizontal or vertical layout? Horizontal being (with *

representing the radio button):
* Fee * Fi * Fo * Fum

Vertical being:
* Fee
* Fi
* Fo
* Fum

Also, I'm assuming people will always want the radio button BEFORE the
label, but would people need control over that as well?

If you want to do something other than the default layout direction but
still not get fancier than that, does layoutDirection make sense as an
attribute?
<form:radiogroup name="foo" labels="Fee,Fi,Fo,Fum" values="1,2,3,4"
layoutDirection="vertical" />

On vertical we'd use <br /> tags between the elements. Horizontal would
simply be a space between elements.

Now if you want to be more explicit by using other HTML tags in your
layout, you'd provide a body to the tag:
<form:radiogroup name="foo" labels="Fee,Fi,Fo,Fum" values="1,2,3,4">
STUFF HERE
</form:radiogroup>

As for how the STUFF HERE bit works, there are some options. The first
one we discussed was modeling it after the Grails radiogroup tag, which
uses data-binding style notation to indicate where the labels and
buttons should go. So this:
<form:radiogroup name="foo" labels="Fee,Fi,Fo,Fum" values="1,2,3,4">
<li>${radio} ${label}</li>
</form:radiogroup>

Would result in the following HTML:
<li><input type="radio" name="foo" value="1" /> Fee</li>
<li><input type="radio" name="foo" value="2" /> Fi</li>
<li><input type="radio" name="foo" value="3" /> Fo</li>
<li><input type="radio" name="foo" value="4" /> Fum</li>

Does that syntax make sense, and do people like it?

LABELS AND VALUES
==================
I'm planning on allowing the following to be used for labels and values:
1. explicit lists (default comma-delimited, but a delimiter can be
provided)
2. structs
3. arrays
4. queries

Explicit lists are in the examples I provided above, but of course they
could be a variable so long as the variable used is a list. If something

other than a comma is used for the delimiter, it would be passed as an
attribute of the tag.

When explicit lists are used, both values and labels must be provided.
Or do people see a need to be able to provide values without providing
labels? Didn't make sense to me but figured I better ask since there
might be a valid use case I'm just not coming up with.

With all the other data types, there are multiple options. These are
proposals--feel free to comment on ANY of this behavior.

Also an overall question: do people want to have the ability to use one
datatype for values and another for labels, or is requiring the same for

both (when both values and labels are provided) OK?

STRUCTS:
* If values is a struct and labels is not provided, the struct key will
be used as the value, and the struct value will be used as the label
* If values is a struct and labels is provided, the struct key will be
used as the value
* If labels is a struct and values is not provided, see the first bullet

above (not sure we really need this option)
* If labels is a struct and values is provided, the struct value will be

used as the label

ARRAYS:
* if values is a one-dimensional array, labels is required
* if labels is a one-dimensional array, values is required
* if values is a two-dimensional array and labels is not provided, index

one of each array element will be used as the value, and index 2 of each

array element will be used as the label
* if labels is a two-dimensional array and values is not provided,
behavior will be the same as above
* if values is a two-dimensional array and labels is provided, index 1
of each array element will be used as the value
* if labels is a two-dimensional array and values is provided, index 2
of each array element will be used as the label
* arrays with more than two dimensions are not supported

QUERIES:
* if a query is used for values, the valueQueryColumn attribute is
required
* if a query is used for labels, the labelQueryColumn attribute is
required
* if a query is used for values and labels is not provided, both
valueQueryColumn and labelQueryColumn attributes are required
* if a query is used for labels and values is not provided, the behavior

would be the same as above
* a different query may be used for values and labels, but
valueQueryColumn and labelQueryColumn are both required in this case

I think that covers what I've been thinking through thus far--your
feedback, thoughts, and questions are GREATLY appreciated.

Thanks,
Matt
--
Matt Woodward
m...@mattwoodward.com
http://www.mattwoodward.com/blog

Please do not send me proprietary file formats such as Word, PowerPoint,

etc. as attachments.
http://www.gnu.org/philosophy/no-word-attachments.html

On Jun 15, 11:33 pm, "Peter J. Farrell" <pe...@mach-ii.com> wrote:

I partly agree with Peter here. Don't have a default layout and don't
even have vertical vs. horizontal or a <p> tag. The output could
simply be the necessary <input type="radio"> piece. I could go either
way on adding a <label> tag by default. If it isn't added, I'd
probably end up doing it myself 99% of the time. Doing this would
result in a horizontal layout, but styling or adding my own <li>, <p>
or <br> tags could change that.

This syntax example of <li>${radio} ${label}</li> seems logical to me.
I haven't looked at how other tags are handling this, but obviously
we'd want consistency where appropriate.

I suppose for a simple True/False, the value and label would be the
same. So perhaps if only values are supplied, use those as the label
also.

Keep it simple here and keep them both the same.

STRUCTS:

How would this work with structs not returning in a consistent sort
order? If I provide a structure and then a list of labels, I don't see
how you could reliably match those up.

Matt Williams

Matt Williams said the following on 06/16/2009 07:39 AM:

Yeah, I'm asking these questions:

* Do we want to get into the business of providing a "default" layout?
* If we do, are we sure the choice of which type of layout really is the
most common?

Another option is to allow people to pass in a layout pattern via tag
attribute so people could parameterize it:

<view:radioGroup path="emailSubscriptionOptions"
layoutPattern="#getProperty("radioLayoutPattern")#"/>

I'd just define the pattern in my XML properties:

<property name="radioLayoutPattern">
    <value><!--//--><![CDATA[//><!--<li><label for="${tag.id}">${radio}
${label}</label></li>//--><!]]></value>
</property>

For example, the options tag (which generates multiple options) when
used with an array uses the array element value for both the value and
label of the option tag.  If you use a list, it uses the list element
for value and label. Structs are just sorted ASC text where the struct
key is the value and the struct key value is the label.
I'd look at the options tags for what I've come up with so far.  We
should make sure they match in functionality.  Too bad we can't use the
options tag for the layout stuff we're figuring out.  Options are part
of a drop down so there isn't any layout stuff to do with that (in the
terms of form element and label placement).
I don't think we should allow independent values attribute and labels
attribute.  It makes for a nightmare as to match up.  As I stated above
for the options tags, I think if we get a struct we should just sorta by
text ASC.

If you want a specific order, I think an array is a perfect choice.  If
it's an array of simple values (strings), use the array element for both
the value and the label.  If the array element has a struct in it, use
the key called value for the radio value and the key called label for
the radio value.  This way you can have an explicit order for your radio
group.

For lists, I don't like the independent values and labels attributes.  
I'd prefer to push people to structs or arrays of structs.  The reason
is that I think independent lists would be developer error prone. Or
allow for lists just like the name / value pairs that BuildUrl() uses
which would keep things inline with the rest of the framework (including
BuildUrl() and the view:a tag):

<view:radioGroup path="emailSubscriptionOptions" items="marketing=Cool
Marketing Emails|product=New Product Notifications|account=Changes to
Your Account" delimiter="|">
    <li><label for="${tag.id}">${radio} ${label}</label></li>
</view:radioGroup>

I think that brings things inline with our the rest of the framework
allows for quasi "ordered" structs via lists.  I'd have to add this
support to the options tag as it currently uses the list element for
both the value and label (it doesn't support quasi structs via lists
using the "=" to indicate the name/value pair).

I'm debating if queries are a good thing but I'm fine with it if people
think it would be useful.  I suspect that some people store this stuff
in a DB so it saves a data transformation step into an array of structs
or other data structure:

<view:radioGroup path="emailSubscriptionOptions"
items="#event.getArg("someQuery")#" labelCol="col1" valueCol="col8">
    <li><label for="${tag.id}">${radio} ${label}</label></li>
</view:radioGroup>

The tag would throw an exception if you use a query and don't provide
the labelCol or valueCol attributes.  The tag would use the query in the
order it is given.  If queries are supported, I'll be sure to add
support for queries for the options tag as well.

Thoughts?  I think these are reasonable and powerful while keeping
things simple and not to confusing.

I'm not to crazy about the two-dimensional arrays such such.  Sounds
confusing (is the first or second array in a two-dimension array the
value or label?) and moreover a pain to maintain for us.

Best,
.Peter

On Jun 16, 2:59 pm, "Peter J. Farrell" <pe...@mach-ii.com> wrote:

I can't see me defining form field layout code in a property. Even on
one form I think radio inputs have different looks:

Gender: _Male _Female

Hobbies:
_Hiking      _Movies
_Biking      _Shopping
_Coding     _Mach-II

I agree. Keep radio options and select options the same as far as
populating values and labels. As for layout, I don't think I'd make it
an attribute of the custom tag at all and force the user to control
layout in the body of the tag as in Matt's original example:
<form:radiogroup name="foo" labels="Fee,Fi,Fo,Fum" values="1,2,3,4">
<li>${radio} ${label}</li>
</form:radiogroup>

If you really want to put an html snippet into a <property> tag, you
could and just reference getProperty() in that body instead.

Agreed. What about javascript/jquery type of syntax with the colon
instead of the equal sign?
items="marketing:Cool Marketing Emails,product:New Product
Notifications,account:Changes to Your Account"
Easier to read in my opinion. I started to wrap it into curly brackets
too but that may throw a CF parsing error or something. Maybe not
though.

Queries would be good and consistent with many regular CF tags also. I
have definitely worked on apps where radio and select options are DB
driven.
I almost wonder if you should do
<view:radioGroup query="qRadioOptions" ...> OR <view:radioGroup
struct="someStructure" ...>

Agreed.

Agreed. I can't see an advantage over structs and 2D arrays generally
have more complexity.

Matt Williams

Matt et al, responses inline below:

Matt Williams said the following on 06/17/2009 07:43 AM:

Well, the more I'm thinking about it -- it seems like it's just
variations on horizontal and vertical radio groups.

I'd prefer not to add the "labels" and "values" attributes just to
support lists.  I'd rather keep things uniform by using the "items"
attribute.  The tag should be smart enough to list that a simple value
is a list, a struct is a struct and a query is a query.

<form:radiogroup name="foo" items="Fee=1,Fi=2,Fo=3,Fum=4">
<li>${radio} ${label}</li>
</form:radiogroup>

Well, I'm not crazy about using JSON like notation because this is CFML
and it's just another syntax to learn and remember to use the tag.  
That's why I suggest name / value pairs using "=" signs -- very
CFML-ish.  Plus, it works like BuildUrl works and I think this is a
place we should try to be consistent.
Yea, that was a fleeting thought for me at first, however you end up
with attribute name explosion (or as I like to call it attribute
namespace pollution).  I prefer the single "items" attribute and plus it
keeps it inline with the options tag.  Lastly, see my comment about the
tag being smart enough to figure it out.

Also, if you are "generating" boiler plate code -- you would have to
change the attribute name you need to use in order generate the code.  
If it's just "items", you don't have to worry about.

Neato.  Although I'm fine with defaulting the value of the valueCol to
"value" and labelCol to "label" by default if they are not defined.  
What do you think of that?

I suggest these datatypes:

* List -- using a "nameA=value1,nameB=value2" format and optional
delimiter attribute to define the list delimiter

<form:radiogroup path="foo" items="Fee=1,Fi=2,Fo=3,Fum=4">
  <li>${radio} ${label}</li>
</form:radiogroup>

* Array -- where the array element is used for both label and value

<form:radiogroup path="foo" items="#event.getArg('someArrayOfItems')#">
  <li>${radio} ${label}</li>
</form:radiogroup>

* Array of structs -- where the struct has label and value keys (useful
for explicit order)

<form:radiogroup path="foo" items="#event.getArg('someArrayOfStructs')#">
  <li>${radio} ${label}</li>
</form:radiogroup>

* Struct -- where the struct key name is used for the value and the
struct key value is used for the label (ordered for text ASC since CFML
structs do not have a consistent output order when looping over them)

<form:radiogroup path="foo" items="#event.getArg('someStruct')#">
  <li>${radio} ${label}</li>
</form:radiogroup>

* Query -- used with valueCol and labelCol attributes to define which
columns to use

<form:radiogroup path="foo" items="#event.getArg('someQuery')"
labelCol="name" value="id">
  <li>${radio} ${label}</li>
</form:radiogroup>

I think this is a pretty much covers all the bases in a consistent
manner (in the terms of the rest of the framework's notations and the
options tag).

.Peter

Consider this the follow-up email I promised on datatypes--this seemed
like a good place to pick up the discussion.

I've been messing around with this a lot today, and I personally don't
like the "Fee=1" syntax. It's easy enough for the tag to know what data
type it's getting, but if I already have two lists and I want to use one
for values and the other for labels, if I want the values and labels to
be the same, this syntax would require me to loop over my lists and
format the data in this way for the radiogroup tag. If I can pass values
and one list and labels as another, that seems handy. (Maybe that's just
me.)

I'm not sure how common it is to want to have values and labels be the
same, but if someone wanted to pass in a single list for both values and
labels this gets really ugly. Reason being that the tag would have to
see if it has a simple value, and if it does, it would have to check to
see if that simple value is a nested list by checking for the = in the
outer list elements. That seems OK until you consider cases in which
either value or label has an equals sign in it, and then you're kinda
screwed.

So, what I'd like to propose as a starting point to get this nailed down
is the following for attributes:
* items: used for all data types including lists when you want the value
and label to be the same
* labels: optional attribute used when items is a list and you want to
use a different list for labels

I'm not sure that's ideal. I even thought about making items only for
complex types, and if you're using lists you'd have to use values and
(optionally) labels as the attributes, but I'm not sure that's better.
(I may be overthinking things, but this does get a lot more complex than
I originally thought it would.)

For consistency's sake if "items" works better when the data is
self-contained, meaning if it's a query, array, or struct, that's fine.
But I really hate to make people tweak their lists to get it to work
with this tag.

Right, but see above for the discussion of cases in which either name or
value would have an = in it. Gets messy. And while it's easy to say "if
you think your data might have an = in it, use a different datatype,"
sometimes you just don't know.

Agreed--I don't think we should get into list=, query=, etc. for the
tag, but I think we do need to come to an agreement on the
items/values/labels stuff I outlined above.

I don't have defaults in there at this point, and I have mixed feelings
on it. To me it would be a VERY rare case when you'd actually have
valueCol and labelCol as your db field names, and if you're building a
query from scratch, then you're doing a bunch of work anyway so why not
just pass in the valueColumn and labelColumn attributes to the tag. So
I'm for making valueColumn and labelColumn required.

Do we want value/labelColumn spelled out like that or just
value/labelCol (in other words, spell out column or use col as an
abbreviation for less typing)?

Lists, yes. That syntax, not a fan, and it can cause issues, unless
(just thought of this) we let people pass an outer and inner delimiter,
but yee-uck. ;-) So I'm for having a single list to serve as both values
and labels, or if both values and labels are contained in separate
lists, then labels becomes an additional attribute.

The more I think about it, I'm leaning towards items for complex types,
and values and labels for lists (and single-dimension arrays ... see
below). Or it's easy enough to treat values and items the same if it's a
list I suppose (meaning if you're using a list, you can use either items
or values for one of the lists).

Hope that explanation makes sense.

To me this is kind of the same as lists. Originally I was thinking, what
if I want to use one one-dimensional array for values, and another for
labels, or use a single one for both?

But at the end of the day, A) that situation is probably rare, and B)
it's easy enough to massage the data a bit before passing it to the
radiogroup tag, so maybe we should require that single-dimension arrays
with simple values as their elements ONLY be used in cases where the
value and label are the same.

I already built in two-dimensional array support, however, and I think
that is valuable to have. For each array element, index 1 would be label
and index 2 would be value.

OK--didn't build this in yet but easy enough to add. And I assume this
would HAVE to be a one-dimensional array, and that the struct keys would
literally be called "value" and "label".

This is done, my only question is if people want it to be ordered test
ASC or just left alone. I'm fine either way, just making sure people
know that will be the behavior. (Playing devil's advocate, what if I
want to use a struct and I *don't* want it to be ordered alphabetically?)

Yep, this is done.

Feel like I asked more questions than I answered, but as I said this got
a lot more involved than I thought it would, so I want to make sure this
all jives with what people want to see.

Also, for the output stuff I'm putting output. before everything:
${output.radio}
${output.label}
${output.id}

Let me know if that doesn't make sense.
--
Matthew Woodward
m...@mattwoodward.com
http://www.mattwoodward.com/blog

Please do not send me proprietary file formats such as Word, PowerPoint,
etc. as attachments.
http://www.gnu.org/philosophy/no-word-attachments.html

smime.p7s 4K Download