How Tree fits into MVC pattern

I am beginning to work on an application that has a tree on the left. When an item of the tree is double clicked it opens a panel on the right which will be worked on. Can someone tell how this can be implemented into an MVC design pattern? Or, should some other design pattern be used?

Thanks.

Where is the tree coming from; what does it contain?

The Tree node item would be added as a new task is started. There would be
a node for Manage Flight, Manage Customer. Each would be added to the tree
a the task was selected from a Toolbar. As a sub-node of these was double
clicked a Panel would open to the right of the tree. I just wondered how this would be handled in an MVC environment.

Thanks.

Let's throw out some options:

One believes what happens in Vegas stays in Vegas. I mean the UI. Getting from tree selection to the detail panel refresh event doesn't involve any model data or fancy logic.

Two uses the Window as a mini-controller within the GUI. It decouples the tree panel from the detail panel. One could argue the window is a legit controller in a nested or recursive MVC design. I'm not sure.

Three takes the controller role of interpreting user gestures seriously so all clicks and such go through the controller. This might be overkill or it might be just right if something more complicated was going to happen, like opening a whole new window.

Do any of those sound useful or horrible or whatever?

You have a tasks-tree on the left and a panel (for a document etc.?) on the right.

So in terms of the Model View Controller (MVC) pattern you have two separate models:
- tree model
- panel model.

Both apply the MVC pattern separately. For instance if the panel model state (values) survives clicking other tree nodes then your two models are totally independent from each other except that the panel model creation is triggered by the tree model on behalf of the tree controller.

Is MVC overkill here?
a) If you now or probabely in the future need to have N controllers and / or N views per model then MVC shurely is the right choise.
b) If you are sure that only one controller and only one view is needed per model then you could choose a simpler solution not keeping clear the roles of model, view and controller.

I allways model MVC (for Java/Swing). The initial additional effort usually is compensated soon.

Thomas.

Now you're into the recursive MVC nature of Swing. The "business model" held in a back-end server and mapped to a database never changes while the user is banging away on the tree and viewing different details. The "Swing models" inside the tree and the details panel can have an independent life, interacting all day long with or without visiting the business model. Swing widgets have their own internal MVC going on, which I usually ignore, perhaps at my own peril.

Originally posted by Stan James:
Now you're into the recursive MVC nature of Swing. The "business model" held in a back-end server ...

The MVC pattern may be applied to the system having the model in the backend, as you described, then the client and/or presentation tiers act as Controller and View. This is like the "macro cosmos".

The MVC pattern may and should also be applied to the "micro cosmos" splitting the client itself into Model (fed by the server's model), View and Controller roles. That is, what I described, because of the initial topic:

Originally posted by Barry Brashear:
... an application that has a tree on the left. When an item of the tree is double clicked it opens a panel on the right ...

Swing components implement the Controller and View roles (in an uggly mix ...) and mostly come with a specialized J*Model to be used with the J*-UI-component.

So at the end we have at least three models (not only for Java / Swing):
- the server-side model, usually connected to a persistent storage like a database (recursively; server's Controller&View having client's models).
- the client-side tree model
- the client side panel model (not recursive to but in sequence with the tree model)

Thomas.
[ August 21, 2005: Message edited by: Thomas Taeger ]

In MVC the controller responds to user input - normally updating the model, and any other stuff that needs to be done.

For your application you will need a controller to respond to the tree events, and a controller to respond to panel events. The way that I might structure this could be :

When the user double clicks on the TreeView component, the TreeController updates the TreeModel if necessary and calls a method in PanelController (passing a reference to the node/leaf that was called perhaps). The panel controller sets up the PanelModel object (if needed) and displays the appropriate panel. If a user makes changes in the panel the PanelController is responsible for pushing those changes to the PanelModel.

This would be the simplest way to implement MVC for this setup.

HTH,

Fintan