Peter J. Farrell wrote:
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>
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.
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.
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.
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.
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.
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 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)?
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>
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.
* 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>
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.
* Array of structs -- where the struct has label and value keys (useful for explicit order)
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".
* 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)
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?)
* Query -- used with valueCol and labelCol attributes to define which columns to use
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
[email protected]
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
Description: S/MIME Cryptographic Signature
