I'm a repeater junky. I use em for display, data entry, setup complex validators and other crazy javascript stuff for them, nest them (helped a coworker do 4 nested levels of repeaters), etc.
However, I wouldn't use a repeater for setting up an option button group. I think a better approach is to use the asp:radiobuttonlist control - which is very well suited to creating option button groups, particularly if you have a data source to bind to. It would be a challenge to obtain the value of the selected option as you have it setup in a repeater - because typically all options in an html option group have the same name attribute - and when a form is submitted only the value for the selected button is posted. With a repeater all of your option button names are going to render as:
repeatername__ctl0:_controlname
or something like that - the point being that each one would have a unique name - which foils how option groups are normally posted.
Here's a detailed example (in C#) of how you might setup a radio button list.
First off, the aspx. You could have some simple html like this to setup a radio button list (and a submit button and a label used in this demo):
Code:
<form id="frmTestRadio" method="post" runat="server">
<asp:radiobuttonlist id="rdlTest" repeatdirection="Vertical" repeatlayout="Table" runat="server" />
<p><asp:button id="btnSubmit" text="Submit" runat="server" /></p>
<p><asp:label id="lblResults" runat="server" /></p>
</form>
There are lots of different properties for the radiobuttonlist that let you set it up as you like. The snippet above also sets up a generic submit button and a label for displaying the selected option after a postback.
That's the easy part. Behind the scenes things are a little more involved. First you'd declare your controls:
Code:
protected System.Web.UI.WebControls.RadioButtonList rdlTest;
protected System.Web.UI.WebControls.Label lblResults;
I'm not declaring the submit button because I don't intend to do anything with it in the code behind - it'll cause a postback just by virtue of it being an asp:button (with default properties) - which will be handled in the Page_Load in this example.
Page_Load contains minimal code due to using a subroutine to do the real work:
Code:
private void Page_Load(object sender, System.EventArgs e)
{
if (!Page.IsPostBack)
{
PopulateRadioButtonList();
}
else
{
lblResults.Text = rdlTest.SelectedValue;
}
}
All it does is build up and display the radio button list for a first time hit and show the results of the radio button selection on postbacks.
There are two components to setting up the radio button list. First, you either manually add options or you use a data source. I like using data sources whenever possible. I'm guessing that you have some kind of datasource because of the way you're doing your repeater - you are likely binding something to it in codebehind.
For this demo I've setup a little struct that looks like this:
Code:
private struct SampleData
{
private int m_nValue;
private string m_sText;
public int Value
{
get { return m_nValue; }
set { m_nValue = value; }
}
public string Text
{
get { return m_sText; }
set { m_sText = value; }
}
}
All the struct does is expose a Value and Text property - two pieces you need to do a decent binding for a radio button group (you want your values that are actually selected and the text the user actually sees). The PopulateRadioButtonList() routine builds up an ArrayList of elements (using the struct) to bind to the asp:radiobuttonlist like so:
Code:
private void PopulateRadioButtonList()
{
ArrayList oList = new ArrayList();
SampleData oData;
// Create some sample data.
for (int i = 1; i <= 6; i++)
{
oData = new SampleData();
oData.Value = i;
oData.Text = "Option #" + i.ToString();
oList.Add(oData);
}
// Setup and bind the sample data to the radio button list.
rdlTest.DataSource = oList;
rdlTest.DataValueField = "Value"; // Struct property used for 'value'
rdlTest.DataTextField = "Text"; // Struct property used for 'text'
rdlTest.DataBind();
}
The sample data is generically generated for demo purposes. Many times you'd have a real data source like a custom collection class of objects built from database data, text, xml - whatever. Also most times you'll use a full-on class instead of a struct - but for demo purposes a struct suffices and sometimes I'll use a struct when I need to combine data from many sources to make one datasource to bind to something. The other part of that routine where you setup what gets used for the 'value' and 'text' for each option button and the setting and binding of the data source is pretty standard and somewhat similar to a repeater data bind.
When you combine all of that, you get a nicely rendered html option button group that's very easy to deal with in the code behind. It's easy to see what the selected value is by examining a property of the radiobuttonlist object. You also avoid the carnage of:
<%# DataBinder.Eval(Container.DataItem, "Name")%>
I personally never use <% %> blocks in my ASPX's. For example, with repeaters I prefer to use the ItemDataBound event of the repeater which give me way more control over what and how I display data. I can build up fill in any type of control, bind data sources to dropdowns, build dynamic hyperlinks, use dynamic text, create javascript events that tie into data values, etc - pretty much anything I want. I don't use many data grids but I'm pretty sure they expose similar events. I consider the use of <% %> to be non-.Net-centric and the only reason people use it in examples (even MS) is because giving full-blown examples of how it should be done takes a lot more time, space, and text to explain. But anyways, I'll step down off my soap box now.
If you were to look at the html generated by a setup like this, you'd see something like this (mildly doctored to remove extra html and make it display smaller):
Code:
<input id="rdlTest_0" type="radio" name="rdlTest" value="1" />
<input id="rdlTest_1" type="radio" name="rdlTest" value="2" />
<input id="rdlTest_2" type="radio" name="rdlTest" value="3" />
.Net renders each radio button with a unique ID (handy for client-side scripting and whatnot) but all the option buttons share the same name, which means when the form is posted and sorted out by .Net is can determine which value was selected.
So anyways...if you setup your radio button group as a .Net asp:radiobuttonlist control with appropriate setup behind the scenes then it's easy to get at the 'SelectedValue' of the group. It is also, IMO, the more .Net-centric way of doing a radio button group.
Paul
PS - Full .aspx and .aspx.cs files used for the code snippets above are attached.
