Maneesh Godbole wrote:We have a forum dedicated for testing. Moving thread.
Stephan van Hulst wrote:Maybe you can post your code in an attachment. I would be willing to look at it.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Jelle Klap wrote:I've briefly looked over the code.
(...) 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.
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 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?
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)?
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.
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?