From: Asger Alstrup Nielsen (alstrup_at_[hidden])
Date: 2000-11-29 03:40:42
[Model-view architechture where model has signals for updating the
model, and views have signals for getting updates of the model]
> >Since the connections form a loop, lifetime tolerance simplifies
> >things a lot.
> Wouldn't it be better to have the view make changes by calling directly
> into the model?
If you only have one instance of a model to talk to, it might be
reasonable to go right to the metal. However, sometimes you have many
instances of models that all should be updated (or informed.) Then you
want life-time-tolerant signals with multicasting.
Even if you don't have this multiplicity of models, signals are more
flexible. It gives you a useful extra indirection, that does reduce
coupling: You don't have to include the "model.h" in the "view.h".
Instead, both just include "signal.h".
This is so because you express the interface in the signal signature,
rather than in the member functions of the model class interface.
Yes, the view.h and the model.h has to agree on the signal signature. Or
more accurately, they have to be compatible: The controller can use
adapters to make the signal interfaces compatible when the connections
In this way, you can change the interface of the model without updating
the view, and vice versa. The coupling between model/view is reduced.
> I've been tending to use views that combine View and Controller together
> (although I do use classes to handle mouse tracking). A full blown MVC
> architecture may make sense if you're designing widgets from scratch, but
> it doesn't seem too useful when you're building on top of platform widgets.
I'm not sure which point you are trying to make, but I would think that
the signals/callbacks in Boost should be usable for designing widgets
In particular, it would be mistake to force the users to collapse the
view and control components because the callbacks/signals could not
handle the separation.
Asger Alstrup Nielsen
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk