Matthew Woodward said the following on 07/15/2009 06:46 PM:
> 1. There will be no default layout provided. This also means this
> cannot be used as a self-closing tag.
Yup, sounds good to me.
> 2. Both values and labels will have to be provided if you choose to
> use the radio group tag (if you don't want to do labels, you can of
> course use individual radio tags)
Yes, just to clarify you mean "label" as the text next to the radio form
element -- not a <label> html tag.
> 3. The <label> tag will be included in the HTML output (since this
> gets into id attributes, more on that in the code sample below)
I'm wondering if we should do that by default. See below for a differing
point of view.
> So, the syntax I have working now is this (assume comma-delimited
> lists for all the data now, but other data types will be supported):
>
> <form:radiogroup
> name="myRadioGroup"
> values="1,2,3"
> labels="radio1,radio2,radio3"
> checkValue="2">
> ${radio} ${label}<br />
> </form:radiogroup>
>
> This will result in the following HTML (N.B. the id attribute since
> I'd like feedback on that, and apologies that the line breaks may be a
> bit weird in an email):
> <input type="radio" id="myRadioGroup_1" name="myRadioGroup" value="1"
> /> <label for="myRadioGroup_1">radio1</label><br />
> <input type="radio" id="myRadioGroup_2" name="myRadioGroup" value="2"
> checked="true" /> <label for="myRadioGroup_2">radio2</label><br />
> <input type="radio" id="myRadioGroup_3" name="myRadioGroup" value="3"
> /> <label for="myRadioGroup_3">radio3</label><br />
>
> To parse out what I'm doing there:
> 1. ${radio} is replaced with the radio button itself
>
> 2. An id is added to the <input type="radio" ...> tag that is the name
> of the radio button, followed by an underscore, followed by an integer
> that increments for each member of the radio group. (If people want
> it, it would be easy to support "ids" as an attribute of the
> radiogroup tag.)
>
Well, I think we should replicate what the "radio" tag does which
instead of incrementing a number after the "_", but use the value (it
uses a RegEx to clean out any spaces or other bad characters that should
not be part of ID). The reason is that using an incrementing number
will change the ID if you add additional elements to the radio group in
the future. It's more predictable this way since it's not based on
position (see the radio tag on what I did it).
For example:
<ul>
<form:radiogroup
path="favoriteColor"
values="red,blue,green"
labels="Razzling Red,Brilliant Blue,Greasy Green">
<li>${radio} ${label}</li>
</form:radiogroup>
</ul>
Would output:
<ul>
<li><input type="radio" id="favoriteColor_red" name="favoriteColor"
value="red" /> Razzling Red</li>
<li><input type="radio" id="favoriteColor_blue" name="favoriteColor"
value="blue" checked="true" /> Brilliant Blue</li>
<li> <input type="radio" id="favoriteColor_green" name="favoriteColor"
value="green" /> Greasy Green</li>
</ul>
> 3. The <label ...> tag is added around the label itself
I'm thinking (while I think it is good practice to use the label tag) to
not include the label by default but allow for this:
<ul>
<form:radiogroup
path="favoriteColor"
values="red,blue,green"
labels="Razzling Red,Brilliant Blue,Greasy Green">
<li>${radio} <label for="${attribute.id}">${label}</label></li>
</form:radiogroup>
</ul>
That way you can get at the computed "id" value or any other attributes
we might introduce in the future. Wondering if we should do use a
prefix like this (so it's not confused with Mach-II expressions like
${event.something}):
<ul>
<form:radiogroup
path="favoriteColor"
values="red,blue,green"
labels="Razzling Red,Brilliant Blue,Greasy Green">
<li>${output.radio} <label for="${output.id}">${output.label}</label></li>
</form:radiogroup>
</ul>
> 4. Any layout included in the tag body (in this case the <br /> tag)
> will be left as is
I concur.
Awesome work Matt!
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to Mach-II for CFML list.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/mach-ii-for-coldfusion?hl=en
SVN: http://greatbiztoolsllc.svn.cvsdude.com/mach-ii/
Wiki / Documentation / Tickets:
http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/
-~----------~----~----~----~------~----~------~--~---
