Rob Ashton

That's exactly the scenario I've been pulling this company from over that time :)

When it comes to the question of adding/removing single fields from a page, I step back and look at the problem differently.

For example, in our product there is a page which is shown to confirm whether an action is to happen or not.

On that page, there can be anywhere between 1-5 questions with yes/no answers.

Rather than have switches to turn them off/on, we define the contents of that page in data (XML in this case, but it could be a DSL using Boo or similar), and then render out that page dynamically based on that data.

The same goes for a number of areas in the system, where we replace a set of on/off switches with something that solves the known problem in general instead of just patching in the answers.

Where we can't do that, then in the example of a very few certain forms, we'd define an action specifically for posting the form to, and stick the form itself in a partial view.

For each person who then wanted something different, we'd then use a different action (overriding that default one), which takes in a different view model, and uses its own validation.

That's not to say a lot of the validation logic can't be shared between those actions/view models of course.

I'll keep this question in mind and possibly cover it in a future follow-up blog entry once I've finished this series. :)