Re: [boost] Re: Callbacks Again

From: Jesse Jones (jejones_at_[hidden])
Date: 2000-11-29 18:22:26

>[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.

Operating on multiple documents at once seems like a very rare case. I can
maybe imagine an editor that allows you to do things like replace all the
words in every open document with another word, but this seems like enough
of an edge case that clients should special case it.

>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
>are made.

The view/controller needs three things from the model: 1) notfication of
changes so that it can invalidate itself 2) access to the data so that it
can render something for the user to see 3) mutators so that the user can
change the model. Notification can be handled nicely via callbacks. I can
imagine using some some sort of callback architecture to handle the other
two but it's not a natural solution and it really seems like overkill when
most views will never be reused in other contexts.

>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,

Just giving you some background on how I've been approaching this stuff.

>but I would think that
>the signals/callbacks in Boost should be usable for designing widgets
>from scratch.

sure

  -- Jesse