• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

More on MVC

 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, all.
Although I've done some searching and seen a lot of posts on MVC topic, but still there're some issues I want to hear everyone's opinion on.
Most of Swing components (buttons, comboboxes, textfields, etc.) have their own models. How do we handle those? Basically, I see two possibilities:
a) all these models are created in Controller and then passed to View components' "setModel" method. In this case GUI will be totally independent of controller. But there's another problem: in order to invoke all those "setModel" methods, Controller has to have references to all widgets in View ("getWidgetXXX()" methods are required in View) which is not good, because Controller is tightly coupled to set of components in a View.
b) do not use all these widgets' models in Controller and communicate with View by means of events thrown by View. This gives us another problem - sometimes the data passed along with GUI event is not enough to perform requested operation. Good example is "search" button event - how do we get selected origin/destination values when we capture such event? We need explicit access to comboboxes (or their models) anyway.
How did you handle this, guys?
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I will answer this by saying look at all my previous posts on MVC.
Mark
 
Andrew Hanger
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Mark,
I'm sorry, but I spent a lot of time searching and didn't find the answer. Can you do a brief overview on the issue once again?
 
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
After much research, it came to me that Swing designers had the same question: "how do we pass data from views to controllers so that neither views not controllers are aware of each other?" The poosible solutions seem imperfect, and maybe that's why the Swing doesn't use controllers, or rather, the controllers and views are one thing. I already submitted my assignment, but for my future projects, I decided that the controller should be used only to select views, and not to transport data from views to models.
So, if I were to do my FBN assignment again, I would do MVC as follows:
When the user clicks the "Search Flights" button, handle the even in the GUI and invoke a corrsponding business method in the model:

So the GUI has a reference to the model (but model doesn't know anything about the views). Also notice that the origin and destination are passed from the view. But if the GUI controls that hold the origin and destination change (to say text boxes), only View will need to be modified.
In the Model, the searchFlights() method would look like this:

The fireModelChanged() method above is fired each time there is a change in the model that the views might want to know about, and it looks like this:

This is actually very clever (although I didn't invent this), -- all the views will just implement the ModelListener interface which specifies only one method, modelChanged(String changeType, Object change). Since the second argument is an Object, you can pass whatever information from model to views, yet model doesn't know anything about the views.
So back to the view where we process the notification from the model:

Note that tableModel is the other "model", but instead what it is, -- the table model for the table to display the flights.
Now, I would still use the controller, but only to select the views. This is so that the views don't have to know about each other. For this part, it makes perfect sense to use those callback methods that Mark proposes (since the controller doesn't need any additional information). For example, when the user selects the "Connect to Database" menu item, the controller will intercept the event (as opposed to a business method invoked in the model), and will pop up the connection dialog. But that's it, the controller doesn't do anything else:

When the user specifies the connection parameters in the connection dialog, the view (the connection dialog itself) handles the event and invokes a method in the model that performs the business method of connecting to db:

Again, if something needs to be updated in the views as a result of connection, the model will just fire the same method to notify the views:
fireModelChanged("connectionEstablished", someObjectWithInfo);
It all now makes sense to me, how about you, ranchers?
Eugene.
[ July 17, 2002: Message edited by: Eugene Kononov ]
 
Andrew Hanger
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Eugene,
your approach makes sense to me.
Actually, it's very close to the way I initially designed my UI..
However, having seen a lot of posts on MVC in the forum, I became confused, because the way majority of people build MVC seems different.
 
Mark Spritzler
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am sorry to say this but Eugene's approach causes too much coupling between the GUI and the Model. In a stand-alone app you can get away with this. However, in Web, Three-tier J2EE, and all MVC OOP Design Patterns books will tell you to decouple all the way. This leads to better reusability, easier to maintain, you can switch out the GUI or the Model at any time without breaking existing code.
I used to program with all the coupling, and I have ahd the experience of doing MVC correctly with decoupling. I will tell you profusely that decoupling makes things so much more nicer, easier, and I would never go back the old cludgy way of things being tightly coupled.
When you do a search using Google to get my MVC comments from previous posts, just put in the following, without the quotes. "MVC Mark Spritzler"
You should find plenty. If not let me know
Mark
 
Andrew Hanger
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Mark,
thanks for your patience in answering these questions. I did some search as you proposed and seen some results. But still there are some things not really clear. I tried to put a list of major questions.
I understand that your Controller has references to both View & Model. I understand how you 'hook' View to send events to Controller. What I don't understand is:
1. How Controller gets data from GUI in cases when required data is not passed along with GUI event. Example: search button fires action event to Controller when user wants to do a search, but how Controller gets access to search criteria which is not passed inside ActionEvent?
I see two possibilities of solving this:
a) Controller calls GUI methods (getOrigin() & getDestination() in the example). I don't like this approach very much because such methods produce tighter coupling between Controller and View and, moreover, this methods have nothing to do with screen layout and hence should not belong to View.
b) Controller has references to the models of widgets used in GUI. Like for all textfields & dropdowns you keep a reference to their models in Controller. That's not good in my understanding, because Controller has to know about all widgets in GUI thus producing a very tight coupling. If I wanted to change JComboBox to JTextField I will have to make changes to both View & Controller.
Maybe I miss something?

2. Whenever Controller receives events from GUI and performs required actions on the Model, the Model changes. How does GUI get updated in such case?
Again, there are same solutions as above and none of them seems good to me.

Now why I feel that Eugene's solution is the most adequate:
As I understand MVC pattern, the greatest achievement it provides is that you can create different Views for same Model. Of cource you can think of the situation when same View is used for different Models, but that's not so common. So it's ok to have View referencing Model, but not vice versa. By giving View a reference to Model all the above issues are solved.
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


I am sorry to say this but Eugene's approach causes too much coupling between the GUI and the Model.


The coupling between the model and the views in my approach is really loose, -- the model dooesn't know anything about the views.
But talking about a "complete separation", your approach has not accomplished it either. It seems very inelegant to me to have GUI controls declared public and to let controllers access them directly. It is obvious that in your implementation if the GUI control changes, the controller must change as well. You never addressed this big hole in your previous posts, Mark, and I think that's what the original poster is asking about. I suppose you may suggest that the GUI controls can be declared private and the accessor methods could be provided in GUI, but if you have a complex form, you may end up with a hundred of accessor methods to maintain. In my approach, you don't have this problem by design.
Eugene.
 
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are many different interpretations of the MVC pattern. Just look through the certification results and you'll see people with very high scores who have implemented it in completely different ways. As long as you can justify your method, you'll be fine.
 
Mark Spritzler
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In my apporach I can change out the GUI, the controller, and the model at any time without interruption on the other classes.
The rules of encapsulation means that there are not public access to the components on the GUI, there are just assessor methods for just the componenets that you will need access to. This is the hooks. This is the same as the JavaBeans rules, etc. The GUI in this case doesn't need to know anything about it or have to worry about changes to its internals.
The Model is the exact same way.
The controller, by definition knows about the GUI and the Model. However, you can seperate this knowledge into ActionListener classes that KNow about the controller and the GUI and then just pass calls to and from. This also works. However, I prefer the Controller handling this because the Controller becomes the application. No matter how you slice it, there will be one place which creates instances and passes references back and forth, and to me that is the controller.
You can choose however you wish to do it. And I won't continue this argument. But I would highly recommend you go to this site Page describing Model View Controller.
And also look at this book.
The book especially is the best. That is where I learned about the Hook pattern into MVC, and used it in all my GUI apps.
Mark
 
Andrew Hanger
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
BTW, Mark, I looked at the link (ootips.org) you posted and there it says that "the viewport knows exactly what kind of model it observes" which means that View has a reference to Model. Isn't it exactly what Eugene was doing in his design?
 
Mark Spritzler
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Not exactly. In his design the GUI knows about the controller. In my design the GUI object needs to know a type of model to expect, but not whats in the model.
Mark
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


In his design the GUI knows about the controller.


Not really. In fact, I am using the same callback mechanism that you proposed where the controller handles the action:

But what I am saying is that the controller only handles actions that require selecting the views (such as in the example above where a request to connect to database comes from the main view, and the controller responds by popping up a database connection view). What this accomplishes is that the views don't know anything about each other.
But when the user action requires more than selecting a view (especially if multiple parameters need to be passed), I prefer to invoke a business method directly from the view, using the reference to a model. This simplifies things dramatically, and solves the problem of passing all the data back and forth from GUI to Controller.
Eugene.
 
Mark Spritzler
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

But when the user action requires more than selecting a view (especially if multiple parameters need to be passed), I prefer to invoke a business method directly from the view, using the reference to a model. This simplifies things dramatically, and solves the problem of passing all the data back and forth from GUI to Controller.


Ok the above code is exactly how I did that. But again here you are putting business logic in the View. That's like putting code and html together. It is always better to split that apart. That is what my point is. Now, with your solution there, if I want to change the GUI without any business logic change, then I have to redo all that code in the one GUI into the other. In my proposal, you can change the GUI at any time, very easily.
Mark
 
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

putting code and html together


but that's encapsulation, isn't it?
Great discussion, guys! I've been unit testing the daylights out of my data and server code and am just now starting to dig at the UI. Thanks for the insight.
 
Mark Spritzler
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Chiji since you posted this question on a new seperate thread, I am going to delete your post here. Besides we don't want to return this thread to prominence again
Mark
 
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In Sun's Fundamentals of Swing, Part II, they provide a nice example of using adapters to establish the model-view relationship. I was planning on using this approach to implement the MVC pattern for my FBN project.
- John
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic