Details
-
Type:
Improvement
-
Status:
Open
-
Priority:
Minor
-
Resolution: Unresolved
-
Affects Version/s: Release 1.5.1
-
Fix Version/s: None
-
Component/s: Tag Library
-
Labels:None
-
Environment:Linux/Jetty (doesn't matter)
Description
The "options-collection", "options-enumeration", and "options-map" tags all allow for an HTML "pass-through" value for the "id" attribute. Well, if you think about it at all, that's not really useful - almost of necessity that'll wind you up with every generation option element having the same "id" value, which would rarely be desirable (it's not really even valid).
I think that instead it should be possible to apply the same capabilities that those tags provide for option value and label to the "id" attribute. For options-collection, the "id" attribute (or a new one, to leave the old one around for whatever bizarre purposes it's already serving) should interpret the value as a property reference for the collection objects. For "options-enumeration", it might be nice to have the choice of enumeration value ordinal, or name, or possibly an arbitrary property for bean-enhanced enums. For "options-map", you might want to use the map key for the "id" or maybe a map entry value sub-property.
Giving the options elements unique "id" values allows for simpler client-side code, to (for example) hide/reveal portions of a form based on the value of the pull-down.
That can be done with the option value too, but the "id" would be somewhat more robust.