• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Devaka Cooray
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Knute Snortum
  • Bear Bibeault
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Frits Walraven
  • Carey Brown
  • Tim Holloway

design problem

 
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I am writing graph editor gui application. I try to adhere MVC pattern. I got stuck desiging graph node model class. I am not sure if it should be responsible for knowing its location, state such as selected, not selected, generally about all view pecific stuff.
Should model be aware that it's going to be displayed?

Thanks for help
 
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Generally I try to avoid embedding knowledge of display in domain objects.

A simple way to explain why is to imagine that you have a single domain object (a graph, in your application), but your appication needs to show two views on it. This may be because two users are looking at it, or because it is a 3D graph with different projections, or simply something non-graphic such as an expandable properties panel with details of each node and arc. All of these are views, and all have different needs.

If you build your model with the assumption that it will only ever be used by one type of view, and only one view at a time, all these kinds of uses will cause you a lot of pain. Each of these different views might have its own idea of "selected", and may or may not make use of positional information within the view area.

My recommendation is to build your model to be as independent of views as possible, but provide accessor methods (and listener callbacks, if other views can also modify the model) to give views the information they need to do their jobs.
 
Stary Kapec
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your reply,

Should I then seperate view specific state ("selected", position) from model and move it directly to the view? I understand not every view would have the same state. Perhaps it would be a good idea to create another object acting like view-state-model?

The other doubt I have is, whether "selected" is in fact view specific. To be in a selected state means to behave sort of differently, so it is not only a matter of appearance. This is at least my point of view
[ March 19, 2006: Message edited by: Jasiek Motyka ]
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Jasiek Motyka:
Should I then seperate view specific state ("selected", position) from model and move it directly to the view? I understand not every view would have the same state.



That's what I tend to do. YMMV, of course.

The other doubt I have is, whether "selected" is in fact view specific. To be in a selected state means to behave sort of differently, so it is not only a matter of appearance. This is at least my point of view

The usual way I approach this is to make my models as stateless as I can manage. Although the user may see things as a "select item", "operate on selected item", "select other item" style of workflow, this is not reflected in the model. The model provides stateless, atomic, operations like "operate on item xx". One job of the view is to manage the idea of selection (if it matters, not all views will have this notion). Selecting one or more items is entirely a view operation. The model is ony affected if/when the user requests an operation, at which point the view requests the operation on the selected item(s).

If you have several views with similar selection semantics, it might be sensible to abstract the selection behaviour into some shared component, but that is still external to the model.

Does that make sense?
 
Stary Kapec
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Now I think I understand
Big thanks
 
author
Posts: 288
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also have a look at the observer deign pattern.
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!