The "How to" is gone from the title to be resurrected at appropriate intervals. In my last post, it was brought up in the comments that it was, and I quote, "naff". Wikipedia helped me with a definition which confused me a little because "cheesy" and "tacky" were the exact adjectives I had in mind when I started using the device some eight months ago in a fit of Kubrick-love (and looking over that link: yoy, I gotta stop writing my thoughts down).

No matter, the Hillbilly is nothing if not easily swayed by anonymous commenters. So the "How to" will be limited to posts on Guerrilla Factoring and Code Coverage Nazis and the like. Back to the show!

The topic of the day is MVP and/or MVC within an MDI application and the blog will act more as a sounding board this time around because I'm having trouble putting my thoughts into something concrete I can type. It probably could also apply to a master form that uses MVP/MVC and which contains several user controls that use the same pattern. If it does, that's not my fault.

Here's the scenario: The main container form has a menu item that says Open which will open the currently selected item as an MDI child. And ummm....I suppose that's it really now that I think about it.

Off topic

If anyone needs further proof that comments tend to end up as distracting noise, consider the following comment lifted directly from one of our classes:

//Ajouter le dernier élement ou le premier si aucun AND/OR

Semi-related suggestion: If you're going to cut and paste code from the web, consider translating the exceptions into the users' first language.

At the moment, both the main form and the child forms are monolithic hydra-like beasts forms that contain all presentation logic and a good chunk of business logic. And so, being a diligent hillbilly, I'm adding a presenter to the main form. Clicking on Open passes the call on to the presenter. Which does....?

My first reaction was that it would create the child forms (which I'll call Estimates, mostly because that's what they are) and maintain them. This would be the easiest implementation because it would involve cutting and pasting code without thinking about it too much. But it feels funky to be manipulating Windows.Form objects in a presenter. Plus how would one interact with them? If I wanted to, for example, save an Estimate, would I need to call a Save method on the Estimate view which would delegate to its presenter? Or do I maintain a list of Estimate presenters instead and make the calls directly on them? And so on, and so forth.

Then I took a step back (tripping over the sofa) and thought "what's the model here?" The main form is generally just a window manager, I think, and its model should reflect that. So rather than having the presenter do all the form management, it should delegate to a WindowManager. Which sounds to me like it would be a UI-based model but a model nonetheless.

Jeremy Miller's StoryTeller has a similar UI metaphor (hierarchical view on the left, tabs on the right) and provided some guidance in this regard. It threw me at first with the main form being a mere 68 lines long (compared with ours at 2344 lines). In it, he passes everything off to an ApplicationController, which is managed through his hierarchical view. The ApplicationController has all necessary dependencies injected into it and it handles opening screens, mostly by delegating them on to the panel that is going to house them.

This kind of jibes with the conclusion I had eventually come to above. And this post was a couple of days in the making so don't be assumin' all of this is off the top of my head.

So in summary: The model for the main form of an MDI application is a window manager/controller that knows how to open other windows.

Thanks for listenin' and if the end result makes me look good, I'll come back and let you know how it turned out.

Kyle the Round-about