Relationship between GUI and logic?

[Bruno Desthuilliers]

David C. Ullrich a écrit :
> On Fri, 23 May 2008 09:13:50 -0400, "John Salerno"
> <johnjsal at NOSPAMgmail.com> wrote:
> 
>> "Bruno Desthuilliers" <bruno.42.desthuilliers at websiteburo.invalid> wrote in 
>> message news:4836747b$0$15488$426a74cc at news.free.fr...
>>> Ever heard of the "Model/View/Controller" pattern ?
>> Yes, I have, but I probably don't understand it well enough yet. For 
>> example, I don't  really know what is meant by phrases like "build a model", 
>> "the view registers itself with the model", "interations are sent to the 
>> appropriate controller" -- I may understand them literally, but I get the 
>> feeling that the implementation of these ideas are beyond me. 
> 
> I doubt that.
> 
> I've done things like this. I ended up with just a Model and a View,
> no Controller.

In the code snippet you gave, you do have the controller part - it's 
just merged with the view. Thruth is that the controller part does not 
map to a single, explicit, obvious *component*. It  in fact often 
happens that the controller bits are handled by various components of 
the system.

In the case of most modern GUI toolkits, the OS and GUI toolkit handles 
the first part of the controller stuff : mapping user actions to 
appropriate events, then mapping events to event handlers 
functions/methods - which, since views and controllers are usually 
tightky coupled, are most often than not methods of the view object 
itself - either because the GUI toolkit requires it or because the coder 
found it simpler and more obvious. Now even in the first case, you can 
still factor the controller part out of the view, and have the view's 
event handlers call on the controller. This may help unit-testing both 
the controller and the view and avoid having too much logic into the 
view itself.