1
\$\begingroup\$

A picture says more than a thousand words, so here's a mock-up. The actual choices are different, this is just a sample.

mock-up

A user first has to choose between Red, Blue and Green. Upon selecting an option, additional form elements are displayed, depending on the choice. For Blue, a Date and Font are required.

Currently, there's no need for a third level, but who knows what the future brings. In order to represent this data, I've come up with the following model (after many attempts).

public class SampleWizard
{
    public enum ColourChoice
    {
        Red,
        Blue,
        Green
    }

    public class RedModel
    {
        public IEnumerable<SelectListItem> AvailableShapes { get; set; }

        public int Shape { get; set; }

        public DateTime Date { get; set; }
    }

    public class BlueModel
    {
        public enum FontChoice
        {
            Arial,
            Helvetica,
            Other,
        }

        public DateTime Date { get; set; }

        public FontChoice Font { get; set; }

        public IEnumerable<SelectListItem> AvailableOtherFonts { get; set; }

        public int OtherFont { get; set; }
    }

    public ColourChoice Colour { get; set; }

    public RedModel Red { get; set; }

    public BlueModel Blue { get; set; }
}

I'm using Enums for hard-coded choices, so I can make decisions based on the value. ints come from the database and do not matter in the programmed decision flows.

This works, but I can't help but feel like this is an ugly solution and I'm worried about future modifications. I've never had to make something like this before so I can't make decisions based on past experiences.

The UI design is more or less set in stone, unless strong arguments can be made against it. (I'd need to bring them up to the designer and project manager.)

\$\endgroup\$
2
\$\begingroup\$

Well, i think, you should first ask yourself do you really want to complicate things? Is this something that you will re-use in other places? Because the feeling "i need to create something reusable and extendable" if familiar to every one of us, but the amount of code you'll need to write and debug is not always worth it in the end.

If you answer is "no", then you can simply do a little refactoring: move classes to separate files, replace individual viewmodel properties with Dictionary<ColourChoice, ViewModelBase>, stuff like that. It will end up looking fine.

If your answer is "yes", then i would probably create a tree-like structure from my view models by implementing something like:

interface ITreeViewModel
{
    IEnumerable<ITreeItem> Children { get; }
    bool IsSelected { get; }
    ITreeItem Parent { get; }
}

Then i would create a custom user control wich will display such tree using this interface and specidied DataTemplates (after i will fail to make wpf TreeView work as i want it too yet again -_-). This is a tricky task with plenty of pitfalls, but i think its possible. At least that would be an approach I'd try first.

\$\endgroup\$
  • \$\begingroup\$ It looks like I forgot to mention an important part: this is an MVC app, so all this has to model bind on a form submit. The proposed solutions do sound good for WinForms/WPF, so +1. \$\endgroup\$ – Stijn Aug 20 '13 at 7:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.