design problem

[Stary Kapec]

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

[Frank Carver]

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]

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]

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]

Now I think I understand
Big thanks

[ak pillai]

Also have a look at the observer deign pattern.