designing an ASP.NET MVC partial view - showing user choices within a large set of choices

Question

Consider a partial view whose job is to render markup for a pizza order. The desire is to reuse this partial view in the Create, Details, and Update views.

It will always be passed an IEnumerable<Topping>, and output a multitude of checkboxes. There are lots... maybe 40 in all (yes, that might smell). A-OK so far.

Problem

The question is around how to include the user's choices on the Details and Update views. From the datastore, we've got a List<ChosenTopping>. The goal is to have each checkbox set to true for each chosen topping. What's the easiest to read, or most maintainable way to achieve this?

Potential Solutions

1. Create a ViewModel with the List and List. Write out the checkboxes as per normal. While writing each, check whether the ToppingID exists in the list of ChosenTopping.

2. Create a new ViewModel that's a hybrid of both. Perhaps call it DisplayTopping or similar. It would have property ID, Name and IsUserChosen. The respective controller methods for Create, Update, and Details would have to create this new collection with respect to the user's choices as they see fit. The Create controller method would basically set all to false so that it appears to be a blank slate.

The real application isn't pizza, and the organization is a bit different from the fakeshot, but the concept is the same.

• Is it wise to reuse the control for the 3 different scenarios?
• How better can you display the list of options + the user's current choices?
• Would you use jQuery instead to show the user selections?
• Any other thoughts on the potential smell of splashing up a whole bunch of checkboxes?

Answer 1

Another visual metaphor for choosing is two parallel lists side by side, with select and unselect buttons or drag and drop between them.

In the display-only scenario perhaps you don't even need to show the unselected items.

The advantage of that is that that selected list is concise. I prefer this when the list of options becomes large, as it tends to cosume less real-estate.

As to whether to exploit browser-side presentation stuff such as jQuery or Dojo: browser-side tends to look much nicer, lots of rich UI possibilities, but be significantly more work. Depends how important the quality of presentation is to the people paying for development effort. Increasingly I see a desire for the improved UI look and feel coming from rich browser UI.