MVC for click and drag interface with multiple models

[Olaf Enulfson]

Hello everyone,

I'm still figuring out MVC. In a previous thread (https://coderanch.com/t/512468/Testing/MVC-test-case) I asked some questions about how to rewrite a little program to fit the MVC pattern. But I'm stuck again. Could you please help me some more?

So, here is the little program I wrote in Eclipse that puts colored dots on a small JFrame, lets you move them around and change their colors when clicked upon.
http://www.4 shared.com/file/gzvFJsmJ/ColoredDots.html

I'd like to change it in the way this example program is build:
http://leepoint.net/notes-java/GUI/structure/40mvc.html

So I rewrote the main class like this:

package com.whatever.ColoredDots;

import javax.swing.*;

import com.whatever.ColoredDots.model.ColoredDotsModel;
import com.whatever.ColoredDots.view.ColoredDotsView;
import com.whatever.ColoredDots.controller.ColoredDotsController;

public class ColoredDotsMVC
{
  public static void main(String[] args) 
  {
    ColoredDotsModel model = new ColoredDotsModel();
    ColoredDotsView view = new ColoredDotsView();
    ColoredDotsController controller = new ColoredDotsController(model, view);   
  }
}

My first question is, what if I have more than one model? In my previous program I had a model for the "dot" and a model for the group of dots together. I could also have a complete different type of object that has different functionality and that I want to keep in its own handy model class.

So, how would I go about fusing multiple models? Would I need a controller for each model?

Thank you in advance.

[Jimmy Clark]

One of the more important aspects of understanding the MVC pattern is that the terms "Model", "Controller", and "View" do not translate into a single class for each area. For example, the Struts Controller consists of many, many objects that all interact with each other to "realize" the Controller responsibilities. The View aspect also consists of many parts.

In terms of the Model aspect, this represents the business (domain) logic of the application and typically is many, many, objects all working together to handle their respective parts of the business (domain) functionality.

You will only have a single Model layer. If you have coded functionality in multiple classes, then you should also provide the access point to allow the Controller to effectively communicate with the Model (everything in the Model.) Hope this helps.

[pete stein]

Jimmy Clark wrote:You will only have a single Model layer.....

I'm not sure about this statement, as many problems require different models on different scales, and these may be in different "layers".

[Jimmy Clark]

In the MVC pattern, there is only one Model.

What makes up the Model depends upon the implementation (and business requirements.)

It could be five object-oriented classes and a COBOL application, for example.

Many business requirements (or problems in your terms) may require many different implementations and may have many "layers", classes, scripts, legacy code, etc. The term "Model" covers the sum of all of this.

A single Model may have multiple Views and may have multiple Controllers that work with these Views. However, there is always one Model.

The intent of the pattern is to ease the development and implementation of multiple views to a single business application.

Business applications that do not have a related GUI are not candidates for the MVC pattern.

[pete stein]

Jimmy Clark wrote:In the MVC pattern, there is only one Model.

Where is this written as a requirement? Take a complex library such as the Swing library. In this you will find that most gui components follow a modification of the MVC pattern, and in fact the library heavily uses this pattern, but when you create a Swing application, you will usually use many of these components with their many separate libraries. So it is with many other complex applications that we create that we can create many models for different scale problems and combine them for use in a single application. For example in the well-written Wikipedia article on MVC, you see:

An MVC application may be a collection of model/view/controller triads, each responsible for a different UI element. The Swing GUI system, for example, models almost all interface components as individual MVC systems.

Business applications that do not have a related GUI are not candidates for the MVC pattern.

I'm not sure about this either as there are ways to view information that do not involve GUI.

Can you quote your sources?

[Jimmy Clark]

There is a difference between design and implementation details. What you find in the Swing library is an "implementation", it is not the pattern. In other words, how the programmers implemented the pattern is not the pattern.

So it is with many other complex applications that we create that we can create many models for different scale problems and combine them for use in a single application.

You are not creating "many models", you are simply implementing the Model for a single application. Model is the abstract design concept. And all the complex applications you are using are part of the "implementation." Implementation details and the higher-level design concept are very different.

Wikipedia is not really an objective or reliable source of information. It is simply a set of unmanaged HTML pages, typically with only cursory information which is in many cases not accurate.

[Olaf Enulfson]

Jimmy Clark wrote:One of the more important aspects of understanding the MVC pattern is that the terms "Model", "Controller", and "View" do not translate into a single class for each area. For example, the Struts Controller consists of many, many objects that all interact with each other to "realize" the Controller responsibilities. The View aspect also consists of many parts.

Ok, so I guess it highly depends on the complexity of the real-world problem at hand how many classes each of these aspects are made of? Is there some guide that can help me determine what component-classes I need to address my real-world problem?

Jimmy Clark wrote:In terms of the Model aspect, this represents the business (domain) logic of the application and typically is many, many, objects all working together to handle their respective parts of the business (domain) functionality.

You will only have a single Model layer. If you have coded functionality in multiple classes, then you should also provide the access point to allow the Controller to effectively communicate with the Model (everything in the Model.) Hope this helps.

So, as if the Model layer is really the logical interface between the business logic objects, and the controller for each view? (If there is more than one view).

pete stein wrote:

Jimmy Clark wrote:Business applications that do not have a related GUI are not candidates for the MVC pattern.

I'm not sure about this either as there are ways to view information that do not involve GUI.

I don't totally understand this, but I think it's a very important point for my project. I also have information that will be part of the model, that will not translate directly in a visible screen element, but that nonetheless will allow or impeach manipulation of the main graphical elements.

You see, my intent is to program some kind of theoretic editor that allows the user to manipulate colored shapes, but with a large amount of rules where these shapes can be positioned relative to each other. As I learn more about the real-world behavior, I will need to add rules to the editor/simulator.

You could compare it a bit to a game of Go, where placing and removing certain pieces triggers a number of requirements (not everything is allowed and some placements are better than others). But the program will also need to offer several solutions where pieces may be placed.

My project is not Go. (It's not even a game. It is more complex than Go, not concerning winning strategies, but concerning allowed placements). But it has comparable interface analogies. So I was hoping to build a framework with the graphical interface that would later allow me to add the business logic rules.

[Jimmy Clark]

So, as if the Model layer is really the logical interface between the business logic objects, and the controller for each view? (If there is more than one view).

In a completely OO system, the Model (shorthand for business model or domain model) represents all of the business/domain objects that execute business/domain-related logic. It is the most important part of the system. There can be multiple Views for this part of the system, e.g. HTML browser, Desktop application, Wireless device, command-line interface, etc.

The role of the Controller is to serve as a delegate between the Model and either one View or multiple View(s). Whether there is one Controller or not depends on the implementation, i.e. if there are multiple Views for example.

Business applications such as batch data processing application which do not invlove human interaction are not candidates for the MVC pattern.

The Model-View-Controller design pattern is for applications that invlove human input. Humans interact with an interface, e.g. HTML browser, command-line prompt, etc., by entering data and/or clicking buttons. They interact with the Model part of the application via View.

I also have information that will be part of the model, that will not translate directly in a visible screen element, but that nonetheless will allow or impeach manipulation of the main graphical elements.

Ok. This is normal. Everything in the Model will not translate directly to a View element. The purpose of the View is to display data and/or input controls for the human user. There typically is a ton of stuff that is happening behind the scenes which the human user never sees, e.g. data manipulation, calculations, processing, connectivity, service invocation, etc.

[Olaf Enulfson]

Jimmy Clark wrote:The role of the Controller is to serve as a delegate between the Model and either one View or multiple View(s). Whether there is one Controller or not depends on the implementation, i.e. if there are multiple Views for example.

Ok, important sub-question then, if I have one JFrame in which the same data is represented in two parts of the screen, one that allows manipulation of the data and one that basically serves as a graphical scroll bar, do I then have one or two Views? And if I have two, I suppose I need two Controllers?

Business applications such as batch data processing application which do not invlove human interaction are not candidates for the MVC pattern.

Yes, of course. That makes sense.

The purpose of the View is to display data and/or input controls for the human user. There typically is a ton of stuff that is happening behind the scenes which the human user never sees, e.g. data manipulation, calculations, processing, connectivity, service invocation, etc.

I don't know if you've looked at my program (ColoredDots). Does that already count as MVC (even though I don't have a controller)? And if not, is it good to model after the MVC calculator example on this page?

And a question for Pete Stein: I see you guys disagree on some points. Are these of major importance concerning my ColoredDots test case program? (Should I be worried?)

Thanks to both of you so far.

[Jimmy Clark]

Ok, important sub-question then, if I have one JFrame in which the same data is represented in two parts of the screen, one that allows manipulation of the data and one that basically serves as a graphical scroll bar, do I then have one or two Views? And if I have two, I suppose I need two Controllers?

The elements of the design pattern, Model View Controller are abstract, high-level design aspects. A View represents a set of something that presents a certain style of interface. It is not a single HTML page, it is not a part of a HTML page either. A View is all of your HTML pages or it is the entire desktop application.

In terms of your JFrame, the entire screen is your View implementation. You could have a thousand little things on the screen, this is all part of your implementaion of a View.
Your Controller is responsible to accepting data from the Model and making it available for your View. Code in your View will display it in any way you code it.

Software design and the actual code are not the same. Design, MVC is a design pattern, does not dictate or control or specify how things should be coded. A design is a separate entity than the code that implements the design. And when you are coding, you shouldn't be trying to map or connect things too much to design terminology. There oftenn is no logical direct match between the too.

[pete stein]

Olaf Enulfson wrote:

Jimmy Clark wrote:The role of the Controller is to serve as a delegate between the Model and either one View or multiple View(s). Whether there is one Controller or not depends on the implementation, i.e. if there are multiple Views for example.

Ok, important sub-question then, if I have one JFrame in which the same data is represented in two parts of the screen, one that allows manipulation of the data and one that basically serves as a graphical scroll bar, do I then have one or two Views? And if I have two, I suppose I need two Controllers?

Business applications such as batch data processing application which do not invlove human interaction are not candidates for the MVC pattern.

Yes, of course. That makes sense.

The purpose of the View is to display data and/or input controls for the human user. There typically is a ton of stuff that is happening behind the scenes which the human user never sees, e.g. data manipulation, calculations, processing, connectivity, service invocation, etc.

I don't know if you've looked at my program (ColoredDots). Does that already count as MVC (even though I don't have a controller)? And if not, is it good to model after the MVC calculator example on this page?

And a question for Pete Stein: I see you guys disagree on some points. Are these of major importance concerning my ColoredDots test case program? (Should I be worried?)

Thanks to both of you so far.

My take on this is yeah, each MVC triad will likely have one model, but your complex GUI application is going to have multiple such triads each interacting with the other. For instance if this were a role playing game, then the game environment would use a large MVC to control it, each player would have one or likely more MVC triads, each weapon an MVC triad, and so on and so forth. Basically a large MVC triad for large-grained concepts such as the game board and game control, and small grained MVC triads for smaller grains of concept such as a weapon or a component of a weapon.

YMMV.

[Olaf Enulfson]

Jimmy Clark wrote:A View is all of your HTML pages or it is the entire desktop application.

pete stein wrote:My take on this is yeah, each MVC triad will likely have one model, but your complex GUI application is going to have multiple such triads each interacting with the other.

The GUI of my application shouldn't be that complex: a static background and simple shapes that can be created, moved about and deleted using point,click&drag, plus a convenient way to scroll around. Positioning and repositioning the shapes around should trigger rule checks that color the shapes to indicate different error levels as to why a position is not good. (With perhaps a log that gives extra information which rules apply, but that is less important). On top of that, and here's the kicker, the possibility to add a cluster of shapes either through combo boxes or a context menu, filled with a possibly great number of precalculated formations of shapes. The latter is probably the most difficult of the logic.

The difficulty is really the rules that will determine which combinations and formations of clusters of shapes are allowed.

Jimmy Clark wrote:In terms of your JFrame, the entire screen is your View implementation. You could have a thousand little things on the screen, this is all part of your implementaion of a View.
Your Controller is responsible to accepting data from the Model and making it available for your View. Code in your View will display it in any way you code it.

So, the piece of code in post #1 could pass as a base class? Or can some things be improved?

Jimmy Clark wrote:And when you are coding, you shouldn't be trying to map or connect things too much to design terminology. There oftenn is no logical direct match between the too.

I'll try to remember that. To be honest, I don't give a rodent's rectum what it's called as long as I get it to do what I need. :-)

pete stein wrote:YMMV.

Well, my vehicule lacks some road testing altogether. ;-)

[Jimmy Clark]

Your concept of "MVC" triads is interesting. However, it sounds like you will also have redundant "plumbing" code in the Controller function, i.e. similar logic repeated over and over again.

[pete stein]

Jimmy Clark wrote:Your concept of "MVC" triads is interesting. However, it sounds like you will also have redundant "plumbing" code in the Controller function, i.e. similar logic repeated over and over again.

Still debating the point? It's not my concept but a standard of the industry and as mentioned is how the Swing library works -- each widget has it's own model and view. It's also a view espoused by no less than Martin Fowler: GUI Architectures

[Olaf Enulfson]

Mkay....

So, pete, how many triad do you think I need for the program described in my previous post? And how do I need to adapt the code in post #1. And Jimmy, according to your take, how does my code look to you?

I've got some more advanced questions in the pipeline, but first I need to know where I stand.

[Olaf Enulfson]

I read Martin Fowler's GUI Architectures. Thanks pete. I understand better now what triads I need.

A triad of MVC will manage the application, where the View is the JFrame (size, background, ...). When a user clicks on an empty space of the screen, the Controller will be notified and instantiate a triad of objects from the shape triad, whom's View will only manage the location and color of the shape.

Now when an existing shape is clicked upon (which is supposed to cycle its color in ColoredDots), does the main Controller (the one that manages the application) intervene? Does it send a message to the appropriate shape controller? Or does that controller get its own mouse handler?

I've also read further about the MVP architecture, and I think my project will have the same problem as the variance display flaw, since the shapes change color based of the status of the shape model, including other shapes. I'm reading Potel's white paper on MVP at the moment.

[Olaf Enulfson]

I read Potel's white paper too, but I think it's a commercial for an IBM product. Although his thoughts on MVP are interesting, it's too far ahead of my current problems.

Now, I've found this article on JavaWorld that at first look seems to agree with Jimmy's point of view of a single Model.

I think the difference lies in semantics: whether the Model part of an MVC triad (as pete named them) is a totally independent Model, or is a part of a greater whole that deals exclusively (or not) with its own View and Controller, depends really how you look at the beast.

In the case of my project, I want the Model of each shape to have its own View (a colored circle in ColoredDots) and its own Controller (a mouse controller actually), but be part of a greater whole of objects representing the structure(s) the shape is part of with some of the other shapes, and the rules that allow or forbid relative certain positions of the shapes.

So, if I want to use the Observer/Observable classes Todd Sundsted talks about in his JavaWorld article, I'll need the View to have a reference link to the Model. So I guess this would become my basic code:

public class ColoredDotsMVC
{
  public static void main(String[] args)
  {
    ColoredDotsAppModel model = new ColoredDotsAppModel();
    ColoredDotsAppView view = new ColoredDotsAppView(model);
    ColoredDotsAppController controller = new ColoredDotsAppController(model, view);
  }
}

Any thoughts on this, please?

Now I have a more practical question: how do I hook up a mouseListener or a mouseAdapter to the Controller instead of to the lPane in the View in my ColoredDots source? I think I can figure it out using events in case of standard controls (a button or a textfield) but what if my user input is the location of a dragging mouse pointer? How do I manage the mouse input in the Controller if Swing has it associated with the visual part of the interface?