15 Jan
2010
15 Jan
'10
9:51 p.m.
On 15 Jan 2010, at 12:41, Alexandre Bergel wrote:
You are right on both points ...
In that case your solution would be cleaner, yes.
- each of
these has a status (a famix property) responsible for
keeping its visualisation state
But you're relying on properties in the model. Which could not
always be the case. For example, imagine I deal now with numbers,
plain instance of SmallInteger. Numbers cannot be annotated. Where
would I store the fact that a node is expanded or not?
Moreover, by using the properties of FAMIX objects to store the
"state" of the visualization (i.e., node that are expanded), your
model is somehow aware of the visualization. This is not what can be
called a clean separation of concerns :-)
I like this because
- I dont need to add vars to the classes
Right, but your model support properties. - the
visualisation state is permanent: if I do a full refresh
nothing is lost
Good point! This is something I will have to take care of [...]
The annotation mechanism should not have any impact on
your existing
code by the way. More I think about it, more I am think this is the
way it should be.
Go for it then ;-)
--
Johan Fabry
jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile