Это, как я хотел бы связать RadioButtonLists. Модель просмотра имеет набор моих сильно типизированных объектов. Например, возможно, PaymentOptions - это таблица кодов. Наряду с коллекцией вызывается SelectedPaymentOptionKey (или Selected * Id, если вы префикс своих первичных ключей с Id). Первоначально этот ключ будет только по умолчанию 0, но при обратной передаче он будет удерживать значение выбранного элемента.
public class PaymentSelectionVM
{
public ICollection<PaymentOption> PaymentOptions { get; set; }
public int SelectedPaymentOptionKey { get; set; }
}
public ViewResult PaymentSelection()
{
var paymentOptions = db.PaymentOptions.ToList();
return View(
new PaymentSelectionVM {
PaymentOptions = paymentOptions,
//This is not required, but shows how to default the selected radiobutton
//Perhaps you have a relationship between a Customer and PaymentOption already,
//SelectedPaymentOptionKey = someCustomer.LastPaymentOptionUsed.PaymentOptionKey
// or maybe just grab the first one(note this would NullReferenceException on empty collection)
//SelectedPaymentOptionKey = paymentOptions.FirstOrDefault().PaymentOptionKey
});
}
Тогда в представлении:
@foreach (var opt in Model.PaymentOptions)
{
@*Any other HTML here that you want for displaying labels or styling*@
@Html.RadioButtonFor(m => m.SelectedPaymentOptionKey, opt.PaymentOptionKey)
}
m.SelectedPaymentOptionKey служит двум целям. Во-первых, он группирует кнопки Radio вместе, чтобы выбор был взаимоисключающим (я бы посоветовал вам использовать что-то вроде FireBug для проверки сгенерированного html только для вашего собственного понимания. Замечательная вещь о MVC - это сгенерированный HTML, достаточно простой и стандартный поэтому вам не должно быть трудно в конечном итоге предсказать поведение ваших взглядов. Здесь очень мало волшебства.). Во-вторых, он будет удерживать значение выбранного элемента для обратной передачи.
И, наконец, в почтовом обработчике мы имеем SelectedPaymentOptionKey доступную:
[HttpPost]
public ActionResult PaymentSelection(PaymentSelectionVM vm)
{
currentOrder.PaymentOption = db.PaymentOptions.Find(vm.SelectedPaymentOptionKey);
....
}
Преимущество этого по сравнению с использованием SelectListItems это у вас есть доступ к более свойств объекта в том случае, когда вы показываете сетки/таблицу и нужно отобразить многие значения объекта. Мне также нравится, что в хелл-хелперах нет жестко закодированных строк, как некоторые другие подходы.
Недостатком является то, что вы получаете радиокнопки, все из которых имеют одинаковый идентификатор, что на самом деле не является хорошей практикой. Это легко исправить, изменив для этого:
@Html.RadioButtonFor(m => m.SelectedPaymentOptionKey, opt.PaymentOptionKey, new { id = "PaymentOptions_" + opt.PaymentOptionKey})
Наконец, проверка немного изворотливый с большинством всех методов кнопки радио я видел. Если бы мне это действительно нужно, я бы подключил некоторый jquery, чтобы заполнить скрытый SelectedPaymentOptionsKey всякий раз, когда нажимаются переключатели, и поместите [Required]
или другую проверку в скрытое поле.
Другой способ решения проблемы проверки ASP.NET MVC 3 unobtrusive validation and radio buttons
Это выглядит многообещающим, но у меня не было возможности проверить это: http://memoriesdotnet.blogspot.com/2011/11/mvc-3-radiobuttonlist-including.html
Существует HTML-помощник на своем блоге, что может помочь HTTP://jonlanceley.blogspot.com/2011/06/mvc3-radiobuttonlist-helper.html – Jon