What are some patterns for creating views and controllers in an MVC or MVP app?

Question

I'm working on a MVC/MVP GUI for editing a document. The document has a tree structure, with some nodes representing text, others images. The app model also includes a command stack, with commands operating directly on the model.

Since different nodes have radically different controls, I'm planning on implementing individual MVC/MVP triads for each node. Where I'm running into trouble is how to synchronize creation and destruction of the peer V and C components.

My ideas:
- listen on each node for "childAdded" type events, and then create peers based on those events
- use a factory for creating nodes in the model, and have that factory also create the peers

What are some common patterns or best practices for dynamic view/controller generation?

Answer 1

I recommend looking at some of the UI Patterns at this site

As for your specific question I would do the following

The form displaying the nodes would implement a INodeView Interface

One Method of the INodeTreeForm interface would be the ability to add a individual node. It would be passing a Node class created in the NodeTreeScreen object. There will be two key property. The first is the key of the node, and the second is the type of node.

You would add the node in such a way that there is a field on the control that has the key.

Along with INodeTreeForm Interface you would have a INodeView interface. This would cover the view area or the new form you will be switching too.

When you click on the node it passes the key to NodeTreeScreen which tend looks at what type of node it is. It has a collection of INodeView objects. One of the properties of INodeView will be which type of node it is.

You retrieve the right INodeView. You close the current INodeview, set the current INodeView to the one you retrieved, pass it the node, and tell it do display itself.

You have a choice as to what INodeView will talk do. You can have a form/control registered for each of the different type. For example a INodeViewText, INodeViewImage, etc. Or just one omnibus INodeViewForm and let the object implementing INodeView take care of the actual drawing.

Depending on your GUI toolkit this could mean that one form could be implementing a lot of different interfaces.

As for adding, deleting, and creating nodes, this would be done through the interaction between the form implementing INodeTreeForm and NodeTreeScreen. Among the things this will be doing is executing the commands you already created to modify the model.

By implementing every thing behind an interface you can change the implementation without screwing up the rest of the software. The object implementing the different interfaces can change without impacting the other objects as long as they continue to implement the interfaces correctly.

This is a variant of Passive View on Martin Fowler's site.