Ayende @ Rahien

Udi Dahan commented on Composite UI, the designer and IoC

Sat, 02 Feb 2008 12:20:31 GMT

Use a layout manager / docking-thingy library for laying out where things go in the main shell. Other than that, views are independent, supervising controllers manage them via specific I_XXX_View interfaces. Controllers do NOT speak to each other directly. Use commands. Menus (ribbons, and context menus too) also activate commands. Put entities in a wrapped up hashtable (I call it a client-repository). When things get added there, have it raise an event so that controllers can act. Be aware of threading issues if you're doing background communications stuff. I should be publishing a software factory in the next few weeks that wraps up all the relevant frameworks and infrastructure to make this all work easily. Keep fighting the good fight.

Bunter commented on Composite UI, the designer and IoC

Fri, 01 Feb 2008 10:08:26 GMT

How does web differ in this case from winforms? I ran into similar problems with monorail MVC on the first day I tried it.

Steve Campbell commented on Composite UI, the designer and IoC

Thu, 31 Jan 2008 14:45:10 GMT

The classic "pattern" solution to this is the mediator. It is actually quite hard to do a mediator while still maintaining separation of view from controller. What I have successfully done in the past is to code the controller (mediator) against an interface of the view(s). This allows quite a clean separation of concerns.

Andy Knight commented on Composite UI, the designer and IoC

Thu, 31 Jan 2008 09:21:10 GMT

hmmm, the views should need to know about other views should they? The actions come from a controller and go to a view. Therefore each sub controller need only know about its view. The parent controller knows about all other controllers. Jeremy Miller has a similar scenario in his StoryTeller project. A main ApplicationShell form which contains a treeview style explorer and a tabcontrol panel. The explorer and tabcontrol both have their own controllers, but the ApplicationController isnt aware of the views I believe.

Dan commented on Composite UI, the designer and IoC

Thu, 31 Jan 2008 07:54:18 GMT

My solution was to have a generic method on the base IView interface as such: T GetChildView() Then I simply use a generic factory interface to couple the child view to the child controller and create an instance through that. It was the best way I could think of to get both the designer to work and the view to be decoupled (as well as the controller not needing a reference to the container), it adds a bit of extra setup to testing, but just a couple of lines at most.

Lamar commented on Composite UI, the designer and IoC

Thu, 31 Jan 2008 05:35:08 GMT

This is always a challenging scenario, since the presenter (or controller) only knows about IView, and not the implementation (winforms, wpf, console, etc...). This is compounded by the idea of having multiple views within a shell form like you are showing in your example. What we ended up doing was build our own MVP framework to handle the creation at runtime, just like how you said in your post that you know how to do it, but hesitate. The framework is in charge of creating the instances of the classes (view/presenter) then activating them (either showing the form, or embedding it in a panel or tab control or whatever). The heart of the framework is the MVPManager that we wrote. The presenters/views get registered into on startup, along with some parameters so that it knows how to activate the view (i.e show the form), or what target to embed the view controls into. The shell form has x number of winforms control (panels) that act as 'targets' that host the view panes, like you have in your example. We then expose these controls as an extra interface in the view with a target name so that the mvp manager can access it. When we registered the child controls, we tell it what parent control, and its embedded target so then the mvpManager activator knows which view belongs with which target panel. We instantiate the views and presenters with a factory (that just calls windsor to resolve the dependencies). Then add the views to their parent control, set their dock property to full, set any other properties, and we're done. Each view is paired with its own presenter, so in your example, we'd have 3 or 4 views and as many presenters. Like Oren and Graham Nash have said, I agree the presenter/controller should depened on IView, and IView is passed into the constructor of the presenter. Makes it way easier to test that way, and also makes it much easier to swap views (winforms to wpf, or whatever). To navigate between views (i.e. show another dialog form or whatever), the presenter only needs to know the registered target name of the view it wants to activate. (This has allowed us to totally decouple our presentation architecture.) The presenter calls the Activate method on the mvp manager (the presenter has a dependency reference to the mvp manager), and passes in the navigation target name, and some state object it wants to pass to the target presenter. The mvp manager then instantiates the presenter and view and shows the view. Our views never talk to anything except the presenter. To communicate between presenters, we opted to use a shared state object, and raise events on that object to notify the other presenters that something changed. This state object would be passed into the presenter by the mvp manager just after the presenter was resolved from the container. We can reuse any view or presenter in different forms by simply changing the parameters that we registered the targets with in the mvp manager. In one of our applications, we half the forms are wpf and half are winforms. As we migrate to wpf, all we really need to do is build a new window that implements IView, and change one line of registration code. Its incredibly flexible, and the calling presenter has no idea what kind of view the target is -- it just knows its name, and what type of state object it is expecting. Our framework was loosely based on microsoft's UIP 2.0, (not to be confused with CAB since we didn't really like it). We chose the best ideas from UIP, ignored what we didn't really like (like shared objects) and added our own flavours to it to suit our environment. It was a bit of work to get right, but I think we've managed to harness our UI problems, in the same way that you are trying to figure out a good design for your environment. And believe me, I had the same questions last summer as you do now. Ayende, I hope you can come up with a great solution, and let us know on your blog what you end up doing.

P, Throws commented on Composite UI, the designer and IoC

Thu, 31 Jan 2008 00:27:15 GMT

"It is surprising to see how much the web affect my thinking. I am having trouble dealing with the stateful nature of things." Have you tried Webforms? It maintains state quite nicely!

Graham Nash commented on Composite UI, the designer and IoC

Wed, 30 Jan 2008 22:13:52 GMT

I agree with Oren. The Controller should depend on the View not the other way around. If testing is a high priority, then you want as little code as possible in the View as UI code is difficult to test. Put all you can in the Controller, then have the Controller depend on the View, and have the View be unaware of the Controller, lends itself well to testing. This is known as Passive View: http://martinfowler.com/eaaDev/PassiveScreen.html

Rinat Abdullin commented on Composite UI, the designer and IoC

Wed, 30 Jan 2008 22:01:34 GMT

Oren, What kind of switching are you talking about? If the controller needs to switch from one view instance to another at run-time, then that's a problem (although I cannot come up with scenario that requires exactly this scenario). If you are talking about decoupling of controllers from views then that's not the problem at all. Controllers encapsulate logic, views know only about the specific controller interfaces (and a single view can rely on multiple controller interfaces) which tell them what exactly they are supposed to do. Thus the coupling is low, and additionally a lot of controllers are shared between Web and desktop views.

Ayende Rahien commented on Composite UI, the designer and IoC

Wed, 30 Jan 2008 21:46:41 GMT

It has to do with who has control over the execution. For example, this means that the controller has harder time switching view if it need to. I tend to prefer a method that puts the control in the hand of the controller, which then direct the view.

dru commented on Composite UI, the designer and IoC

Wed, 30 Jan 2008 21:34:29 GMT

Ayende, I am in complete sync with you about going to winforms after so much web based development. I look forward to hearing what you have to say on the situation.

Rinat Abdullin commented on Composite UI, the designer and IoC

Wed, 30 Jan 2008 21:33:08 GMT

Oren, How does the execution flow affect the control responsibility? If your computer is woken up by LAN card, do you say the OS is controlled by the LAN?))

Ayende Rahien commented on Composite UI, the designer and IoC

Wed, 30 Jan 2008 21:16:59 GMT

Who request the views from the container? This means that the UI is in control of the application, and I don't want that.

Rinat Abdullin commented on Composite UI, the designer and IoC

Wed, 30 Jan 2008 21:13:59 GMT

Hm, explicitly hooking together views and controllers (when this could be avoided) does not feel good. Why not do the other way around? public sealed class BigCalendarView(ICalendarController controller) {} public sealed class SmallCalendarView(ICalendarController controller) {} and let the IoC handle the rest? You could even close/open views on the fly and let user customize the layout. Blogged about it here http://rabdullin.com/how-to-implement-complex-ui-composition-in-xlim/

Graham Nash commented on Composite UI, the designer and IoC

Wed, 30 Jan 2008 20:55:13 GMT

In those cases I generally have: ParentView : ICalendarView, ISummaryView, IActionView { } Keep your AccountController contructor as is. It thinks it is getting three different views but in reality is getting the same object three different times. IoC will hide this from the Controller. I find this to be the most designer friendly.

Ayende Rahien commented on Composite UI, the designer and IoC

Wed, 30 Jan 2008 20:38:56 GMT

Yes, that is what I wanted to avoid. No real way around that, and I ended up doing just that. It isn't as nice as with the designer, but it works

Bill Pierce commented on Composite UI, the designer and IoC

Wed, 30 Jan 2008 19:50:58 GMT

Would you need to make the ParentView aware of IoC for it to register the sub views? Could you not have: ParentView : IParentView { public ICalendarView CalendarView { get; set; } public ISummaryView CalendarView { get; set; } } IoC would inject them at instantiation. Then you would simple need to add them to the proper place holder control during Load.