• 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

MVC test case

 
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dear coders,

I've written a small program in preparation to write a large program. The idea was to develop a test case in MVC first. Unfortunately the program I wrote is not very MVC yet. I would like some tips from you guys to make it better before I start working on the big program. Would it be ok if I posted the program here (5 classes, 40 to 100 lines each) so that you guys can comment on the mistakes?

The program runs. I wrote it using Eclipse. It has a simpel graphical Swing UI and I use the Observable class for messaging. I have one problem I cannot solve and several style problems that need to be cleaned up.

If I should post it in another place, please let me know.

Thanks in advance. I'll be back tomorrow.
(And I would understand if 250 lines of code are too much for a post)
 
Saloon Keeper
Posts: 15510
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Maybe you can post your code in an attachment. I would be willing to look at it.
 
Bartender
Posts: 11497
19
Android Google Web Toolkit Mac Eclipse IDE Ubuntu Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We have a forum dedicated for testing. Moving thread.
 
Olaf Enulfson
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Maneesh Godbole wrote:We have a forum dedicated for testing. Moving thread.


Well, ok. But it's not really a testing issue. Test case means it's a program to try out some techniques. But if it's read and replied to here, I've got no objection. Thanks Maneesh.

Stephan van Hulst wrote:Maybe you can post your code in an attachment. I would be willing to look at it.


Good idea. Thanks for your time, Stephan.

Attachments don't seem to work, so I signed up for this free data storage account and posted my project there:
http://www.4 shared.com/file/gzvFJsmJ/ColoredDots.html

So, this program is a screen on which dots appear when clicked on. Clicking a second time on a dot, changes its color. You can also drag the dots around. Very basic stuff.

The first issue I have is how to remove a dot by right clicking on it. I understand that a second BUTTON_MASK needs to be checked in method mouseReleased in class DotsGUI. But how does class DotChain receive the message to delete that object?

The other long-term issue is how this program can become more MVC. Actually, there is not even a real controller. I don't expect anyone to rewrite it completely. But maybe you can give me some ideas that I can implement and send back for review. Maybe there are some obvious mistakes I made.

Anyway, thanks a lot in advance.

O.
 
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've briefly looked over the code.

Regarding the MVC implementation, one thing I noticed is that you've clearly separated the view from the model, yet the controller logic remains integrated into the view, and I wonder why that is? I'd start by extracting the controller logic out of the view into a controller, which would interact with both model and view. Also, right now you're updating the DotModel for every single dragged event, which triggers a notify/update cycle that repaints the component. I think it'd be more efficient to short-circuit between the controller and view and update the model only when you have a "definitive" fix on the new location, based on the released event. That way it should even be possible to create an unobservable and immutable Dot and a DotModel that keeps track of them - dropping DotChain entirely. Though I'm not sure how much sense that model change actually makes. I guess the single observable model would reduce overall complexity.

As for removal of dots, that shouldn't be too hard or different from adding new dots (regardless of which model approach you take). Simply manipulate the model from inside the controller when it receives the MouseEvent that should trigger a removal operation (right click). The removal operation on the model should itself trigger a notify/update cycle, which will in trigger the view to (re)paint itself based on the current state of the model. It should take care of itself.
 
Olaf Enulfson
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jelle Klap wrote:I've briefly looked over the code.


Thanks Jelle.

(...) you've clearly separated the view from the model, yet the controller logic remains integrated into the view, and I wonder why that is?


When I read up on MVC tutorials, I understood the Controller to be a link between the Model (the data and the functionality) and the View (the user interface, including input management from the user).

When I later 'discovered' the Observer-Observable framework, I used this as a replacement for the controller-link. (I even found a white paper on MVC demonstrating that, and based my program on it). I understand now that this is incomplete. The controller is really the mouse listeners and event listeners of the user interface, in addition to the message gateway. Right?

I'd start by extracting the controller logic out of the view into a controller, which would interact with both model and view.


So in the Controller I would have to register two observers ( .addObserver(this); ), one to the Model and one to the View? That second one I don't understand. Which changes of the View are to be observed?

And where and how would I connect the mouse listener to the pane (as is currently done in DotsGUI)?

Also, right now you're updating the DotModel for every single dragged event, which triggers a notify/update cycle that repaints the component. I think it'd be more efficient to short-circuit between the controller and view and update the model only when you have a "definitive" fix on the new location, based on the released event.


Ok, but wouldn't the drawn position of the dot be updated only at release? How does the user know where his dot is going to be at release? He needs to see the dot move.

That way it should even be possible to create an unobservable and immutable Dot and a DotModel that keeps track of them - dropping DotChain entirely.


In my big program, I'll need a searchable link between each dot. The relative postition of the dots will have their importance, and will be checked and re-checked at every new dot and every moved dot. So I kind of need DotChain to maintain an easy relationship. If there is a better way to do that, I'm open to all suggestions. At some point I had specific pointers to neighbor dots, but that was overly complicated.

As for removal of dots, that shouldn't be too hard or different from adding new dots (regardless of which model approach you take). Simply manipulate the model from inside the controller when it receives the MouseEvent that should trigger a removal operation (right click). The removal operation on the model should itself trigger a notify/update cycle, which will in trigger the view to (re)paint itself based on the current state of the model. It should take care of itself.


I don't understand this completely. Would there be a Controller for each dot? Or a single Controller managing the entire input interface for the screen and all the dots at once?

... could we take it a little slower? Maybe tackle one of these problems at a time. Your choice is fine to me.
 
Stephan van Hulst
Saloon Keeper
Posts: 15510
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Olaf Enulfson wrote:When I read up on MVC tutorials, I understood the Controller to be a link between the Model (the data and the functionality) and the View (the user interface, including input management from the user).

When I later 'discovered' the Observer-Observable framework, I used this as a replacement for the controller-link. (I even found a white paper on MVC demonstrating that, and based my program on it). I understand now that this is incomplete. The controller is really the mouse listeners and event listeners of the user interface, in addition to the message gateway. Right?


Actually, not even the message gateway. Information should be free to travel directly to the view.

So in the Controller I would have to register two observers ( .addObserver(this); ), one to the Model and one to the View? That second one I don't understand. Which changes of the View are to be observed?

And where and how would I connect the mouse listener to the pane (as is currently done in DotsGUI)?


No, the controller should implement the interfaces used in your view, for instance, ActionListener, MouseListener, etc. Interfaces like these actually already follow the Observer/Observable pattern. They are simply more specialized.
Then you pass your controller to the various addListener methods of your view.
Your controller should not even need to observe changes in the model, because there's nothing it will react to. The view observes the model, and shows the changes. The controller merely needs a reference to the model in order to perform changes on it, in case of an event from the view.

Ok, but wouldn't the drawn position of the dot be updated only at release? How does the user know where his dot is going to be at release? He needs to see the dot move.


In that case your implementation is correct. I only looked over it quickly though.

I don't understand this completely. Would there be a Controller for each dot? Or a single Controller managing the entire input interface for the screen and all the dots at once?


The latter. The controller will receive events from the view, after which it will make changes to the model. After the changes, the model will notify its observers that it has changed. The view is an observer, so it will automatically react when the model has changed.

Furthermore, on line 34 of DotChain you're casting a reference to a DotModel to..... a DotModel.
 
Olaf Enulfson
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your help, Jelle and Stephan.

I haven't replied in a while, I'm sorry about that. I haven't I stopped working on my project though. I've got a few follow-up questions in another thread. If you have the time, I'd appreciate your input.

Here is the thread:
https://coderanch.com/t/517878/patterns/MVC-click-drag-interface-multiple

Thanks again.

O.
 
Those are the largest trousers in the world! Especially when next to this ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic