Pattern for ASP.NET MVC View Hide/Unhide Controls

I am looking for a POEAA

I have a standard ASP.NET MVC View with tons of input controls. The visibility of the controls is triggered based on inputs from 2 main dropdown controls. for e.g. DropDown1 with value A and DropDown2 with value B will show only few controls from the full list and will also change the mandatory requirements.

How should I design the view?

1. Write java script and hide/unhide based on the DropDown combinations.There can be 30 combinations so might be challenging to manage on new controls and combinations

2. Create a table in database that will give a list of control ids for each combination and then on client side loop through it to hide/unhide?

3. Any other patterns someone can suggest? Aim is to keep it clean and manageable

Real World Example

Working on a property listing form. Based on the selected property type and transction type, the controls are hidden/shown.

For e.g. Bedrooms and Bathrooms do not apply to a Plot/Land. There are 2 dozen such controls whose visibility needs to be managed based on the property type/transaction type comibination.

The list can grow...

Thank开发者_开发问答s, Pinakin

---

I would suggest looking at a more reactive approach by implementing the MVVM pattern and would suggest looking at knockout.js as a method of binding your model to your controls and their attributes such that changing your model will have effects beyond the value being changed.

Hopefully this will give you some ideas on how to move forward but I stand by my original comment, look to re-evaluate how you are presenting the user interface. 30 controls on a single view is too much. Break it down into smaller chunks, if it's tough for you to manage then it's tough on the user too.

---

For a web based app you should be looking to decompose any complex input screens into the least complex views as possible, primarily from the users point of view.

For example, rather than modify one monolithic options page, have the drop down combinations direct the browser to a page/view that is specific for that combination.

You will end up with a number of specific pages/views, but you are left with a number of advantages:

1. User is not presented with a radically changing web page that may confuse them

2. A less complex page results in a lower chance for problems due to a partial page load

3. Your pages/views are encapsulated: You know any changes will affect only that combo

Repetition can be minimised through the use of includes/user-controls and common code blocks to keep your code as DRY as possible.

---

How about using the property type and transaction type as action method parameters, and then displaying different views based on these? You could then have the resulting form post back to different actions depending on the context, which would make validation easy. I think that's an approach that is pretty maintainable. (Of course, you could still add UX improvements such as loading the view via AJAX instead of full redirects.)

You could have a common base class for the view models for the different scenarios and use the EditorForModel helper to display the proper form for each derived type.

public abstract class PropertyViewModelBase { ... }
public class ApartmentForRentViewModel : PropertyViewModelBase { ... }
public class LandForSaleViewModel : PropertyViewModelBase { ... }

Then in your controller:

[HttpGet]
public ActionResult AddProperty(int propertyType, int transactionType) 
{
    PropertyViewModelBase viewModel = // Perhaps a factory that returns an
                                      // empty instance of the proper type?

    return View(viewModel);
}

Somewhere in the (strongly typed) view:

@model MyApp.Models.PropertyViewModelBase

[...]

@Html.EditorForModel()

And you'll have to define an editor template (partial view) for each deriving type of PropertyViewModel. If you would like to have the form posted to different action methods depending on property type + transaction type, include the entire HTML form in the editor template.

That's one possible approach, with the benefit of turning a monolithic, gigantic form into several smaller, more specialized ones.