Polymorphism and Cocoa NSViews + bindings

Question

I'm currently developing a Wizard-like feature for my app in which every step model class is a subclass of a base WizardStep class. I just have three of them now (but they will always be less than a dozen).

I have a WizardController to backend the actual wizard NSView and I'm now facing the problem of how to manage this polymorphic WizardStep class in the UI. Please note that I will do extensive use of Cocoa bindings for each of the step subclasses.

Three solutions came to mind:

1) Create separate NSView(s) for every type of WizardStep, then create an equal number of NSObjectController and bind specific subclass properties between them. When the user moves into a step I will populate the content of the NSObjectController and show the view (as a subview, of course) in the Wizard view.

2) Create separate NSView(s) for every type of WizardStep, then create an single NSObjectController and bind all subclasses properties to it (some of them will be unavailable depending on which type the controller content is). When the user moves into a step I will populate the content of the NSObjectController and show the view (as a subview, of course) in the Wizard view.

3) Create a NSTabView with a tab per each type of WizardStep, then create an single NSObjectController (or use the wizard ViewController) and bind all subclasses properties to it (some of them will be unavailable as in solution 2). When the user moves into a step I will populate the content of the NSObjectController and set the selectedIndex property of the tab view depending on the particular step type.

I feel like solution 1) is the most correct and elegant but I'm afraid it can be an overkill (many NSObjectController, many NSView). Solutions 2) and 3) feel like silly to me (because of the unavailable bindings).

Any advice on how to proceed?

Thank you all, Peter

Answer 1

The way I would do this would be to make a single model class that is valid (or at least doesn't raise) for all steps in the workflow, with one property indicating the current step. Then you can bind an NSTabView to the currentStep property, and bind all the other controls on each tab to the properties they display. Even if you're too far down the road to give up on the model-subclass-per-step approach, you could make another model object that aggregates multiple steps into a single object.

This approach means you have one model class instead of X model classes, Y view classes, and Z NSObjectController subclasses. FWIW, I have trouble imagining why one would ever subclass NSObjectController in this situation, and although, in a broader sense, there are plenty of reasons to subclass NSView, I'm not clear on what in this particular scenario demands it.

As for unavailable bindings, you can turn off the option of "Raises For Not Applicable Keys" for bindings that might be unavailable at times, but this can be a pain if you like having a breakpoint on exception throws because turning off that option doesn't stop the exceptions from being thrown, it just makes the controls swallow the exceptions.