Re: Relationship between GUI and logic?

**Bruno Desthuilliers** · Jun 27 '08, 04:26 PM

Re: Relationship between GUI and logic?

John Salerno a écrit :

"Bruno Desthuilliers" <bruno.42.desth uilliers@websit eburo.invalidwr ote in
message news:4836747b$0 $15488$426a74cc @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",

An abstract, logical representation of your board and players, which
have a state (ie : board has X cells, player1 is on cell (x, y) and
player2 on cell (x', y')) and behaviour (ie : player2.move_to (x, y))
that changes the state.

"the view registers itself with the model",

This is the Observer pattern. The view is passed the model when
instanciated, and calls model.register( self). When the model changes
it's state, it calls back the '.notify()' method of each of the
registered views (a same model can have multiple views at the same time).

"interactio ns are sent to the
appropriate controller"

In a typical GUI, the controllers are the event handlers (or are called
from the event handlers - depending on how the GUI works). The system
dispatch the events to the appropriate event handlers.

-- I may understand them literally, but I get the
feeling that the implementation of these ideas are beyond me. I think it's
mainly an issue of terminology, so probably I should just read up on MVC.

Probably, yes !-)

**David C. Ullrich** · Jun 27 '08, 04:26 PM

Re: Relationship between GUI and logic?

On Fri, 23 May 2008 09:13:50 -0400, "John Salerno"
<johnjsal@NOSPA Mgmail.comwrote :

>"Bruno Desthuilliers" <bruno.42.desth uilliers@websit eburo.invalidwr ote in
>message news:4836747b$0 $15488$426a74cc @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", "interation s 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. I assumed that meant I was being Bad - I read once
that that often happens, specifically with GUI programs.

An example, certainly not meant to be definitive, maybe not
even right, probably not "right", but illustrating explicitly
what those terms you claim not to understand might mean
in an implementation:

class Model:
"""Encapsul ates an abstract version of the game:
Knows nothing about how the players make moves,
the moves are reported to the model via the
ProcessMove method. Knows nothing about how the
state of the game is displayed to the players;
that's handled by the view or views. The model
might contain a matrix, where the entry in each
cell is None or a certain Piece object. The model
knows that if a certain Cell contains a King then
it's legal to move that King to this Cell but
not to that Cell - that's part of the rules of the
game, something the View knows nothing about"""

def __init__(self):
#set up internal state, for example
#self.board = [[None]*8]*8
#and then self.board[0,4] = Queen[WhitePlayer],
#etc. Whatever...

self.views = []

#or just self.view = None if there's
#no reason for multiple views. When I did
#something like this once I decided at the
#end that I should have allowed multiple
#views even though there was only one to start,
#because functionality that got added to the view
#could have been done more cleanly by creating
#a second view (one view being the display and
#another being spoken messages)

def RegisterView(se lf, view):
self.views.appe nd(view)
#or just self.view = view

def UpdateViews(sel f):
for view in self.views:
view.UpdateDisp lay(self)

#or UpdateView(self ): if self.view: self.view.Updat eDisplay(self)

def ProcessMove(sel f, move):
"""Model recieves "messages" from View here."""
#modify internal state depending on the
#information passed in "move",
#for example move might say that the Piece in
#a certain Cell was dragged to another Cell.
#Here in ProcessMove you decide whether that's
#a legal move, and if so what effect it should
#have on the state of the game. Update state, then

self.UpdateView s()

#or there could be more than one "Process" method
#if there are various different sorts of things the
#players might do

class Square:
def __init__(self, row, col):
self.row = row
self.col = col

#say a move is a drag from one square to another:

class Move:
def __init__(self, start, end)
self.start = start
self.end = end

#wrote that out explicitly just to emphasize that
#the Move object, which the View passes to the
#Model as a message, doesn't know anything
#about the details of the display and also doesn't
#know anything about the rules of the game...

class View:

def __init__(self, game):
#set up the wxPython stuff
self.game = game
self.game.Regis terView(self)
Bind(self, VariousEvents, VariousHandlers )

def VariousHandlers (self, evt)
#figure out what the players just did based
#on evt. Maybe a player has just dragged a piece
#from one square to another. figure out the row
#and col of the start and end squares from
#information in evt.

#Now tell the Model what just happened:

self.game.Proce ssMove(Move(Squ are(row1, col1),Square(ro w2, col2)))

def UpdateDisplay(s elf):
#look at self.game to figure out what pieces
#go where, then draw them on the screen.
wx.This
wx.That

game = Model()
view = View(game)

>I think it's
>mainly an issue of terminology, so probably I should just read up on MVC.
>

>The user interface doesn't need to be graphical. There were games and
>emails clients and text editors before GUIs existed, you know ?

>
>Of course, but I'm specifically asking about creating a program that has a
>GUI, and even more specifically it would be wxPython.
>

David C. Ullrich

**Bruno Desthuilliers** · Jun 27 '08, 04:26 PM

Re: Relationship between GUI and logic?

David C. Ullrich a écrit :

On Fri, 23 May 2008 09:13:50 -0400, "John Salerno"
<johnjsal@NOSPA Mgmail.comwrote :
>

>"Bruno Desthuilliers" <bruno.42.desth uilliers@websit eburo.invalidwr ote in
>message news:4836747b$0 $15488$426a74cc @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", "interation s 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.

Re: Relationship between GUI and logic?

Re: Relationship between GUI and logic?

Comment

Comment

Comment