Use Html.RadioButtonFor and Html.LabelFor for the same Model but different values

Answer 1

I've been wondering how MVC determines "nested" field names and IDs. It took a bit of research into the MVC source code to figure out, but I think I have a good solution for you.

How EditorTemplates and DisplayTemplates determine field names and IDs

With the introduction of EditorTemplates and DisplayTemplates, the MVC framework added ViewData.TemplateInfo that contains, among other things, the current "field prefix", such as "Items[1].". Nested templates use this to create unique names and IDs.

Create our own unique IDs:

The TemplateInfo class contains an interesting method, GetFullHtmlFieldId. We can use this to create our own unique IDs like so:

@{string id = ViewData.TemplateInfo.GetFullHtmlFieldId("fieldName");}
@* This will result in something like "Items_1__fieldName" *@

For The Win

Here's how to achieve the correct behavior for your example:

    @{string id = ViewData.TemplateInfo.GetFullHtmlFieldId("radioTrue");}
    
    @{id = ViewData.TemplateInfo.GetFullHtmlFieldId("radioFalse");}
    

@Html.RadioButtonFor(i => i.Value, "1", new{id})
    
@Html.LabelFor(i => i.Value, "true", new{@for=id})

@Html.RadioButtonFor(i => i.Value, "0", new{id})
    
@Html.LabelFor(i => i.Value, "false", new{@for=id})

Which will give you the following HTML:

    

    
true


    

    
false

Disclaimer

My Razor syntax is underdeveloped, so please let me know if this code has syntax errors.

For what its worth

It's pretty unfortunate that this functionality isn't built-in to RadioButtonFor. It seems logical that all rendered Radio Buttons should have an ID that is a combination of its name AND value, but that's not the case -- maybe because that would be different from all other Html helpers.
Creating your own extension methods for this functionality seems like a logical choice, too. However, it might get tricky using the "expression syntax" ... so I'd recommend overloading .RadioButton(name, value, ...) instead of RadioButtonFor(expression, ...). And you might want an overload for .Label(name, value) too.
I hope that all made sense, because there's a lot of "fill in the blanks" in that paragraph.