Hi Matt, Perhaps I'm missing something, but why don't you just make your own IWizardModel implementation? It would hold your wizard steps and subwizards and map whatever behaviour you want to the IWizardModel interface.
Thomas > -----Original Message----- > From: Matt Jensen [mailto:[EMAIL PROTECTED] > Sent: Dienstag, 25. September 2007 18:01 > To: [email protected] > Subject: Nestable Wizard Models > <snip....> > > My current solution to this problem involves a new class > which maintains a list of IWizardSteps outside of any > IWizardModel; that object has a method which can be called to > "inject" those wizard steps into any given IWizardModel. As > it injects those steps, it also applies a single condition > across all of them...possibly merging it (using "and" > semantics) with the ICondition implementation on the step > itself. While this setup works, and it does allow a single > condition to cover several steps in a single model, it just > feels "clunky." I can't help but feel that a better way to > do this would be to allow WizardModels to be nested, possibly > linked with IConditions. This would afford complete (I > think?) reusability of models in this "splicing in" scenario. > </snip>
