[Tkinter-discuss] Where is place for "Events" in an OOP script?

[Wayne Werner]

On Wed, Oct 5, 2011 at 11:26 AM, GKalman <kalman_g at msn.com> wrote:

> I'm trying to separate the GUI and Non-GUI type classes in my script. *For example:
> * Say, I have a Spring class ( with all the non-GUI type attributes of a
> mechanical Spring) and a DisplayBoard class (for all the Tkinter type
> displays on a Canvas object). For simplicity, assume I want to drag an
> instance of the Spring across the Canvas. *Questions:* (1) Do the actions
> defined thru the "bindings" and associated callback-functions "belong" to
> the Spring class or the GUI class? (2)Should there be a separate "Actions"
> class that ties the Spring (non-GUI) class and the DisplayBoard (GUI) class
> together?


Helpful tip: proper formatting (spaces between lines, numbered lists on
separate lines) is helpful to us when we try to read your email.

To answer your questions, it depends on what pattern you're using. You might
want to take a look at the Model-View-Presenter design pattern. There are
several other patterns that help decouple your design, but to me this
pattern sounds like it answers your questions.

If you use the MVP pattern, the View would be your GUI (at least in this
case). From what I understand, in the most "pure" version of MVP, the only
thing the view does is display data, and pass events to the presenter. The
presenter is where all the logic (i.e. "Doing stuff") happens.

In your particular example, it sounds as if you have "things" that you're
moving around on a "board". So from an MVP standpoint, your presenter might
have a Board instance. That Board would have its dimensions and any other
attributes it might need, and possibly a collection of items that are on the
board. Then the View will have access to the Board via the presenter, and
based on the data in the Board object and the items it contains, it will
draw certain things.

Then depending on how strict you want to adhere to the MVP pattern, when you
click and drag an item, you might bind the MouseDown event to
presenter.selectItem(x, y) - and the presenter would set its .active_item to
the item at (x,y). Then you would bind the MouseMove event to
presenter.move_item() that might take either an absolute x,y position or a
delta-x/y. Finally, you would bind the MouseUp event to
presenter.release_item() that would set the .active_item to None.

The beauty of this pattern is that now you can easily plug-and-play with
different views. Instead of using Tkinter, maybe you want to use PyGTK -
that's fine, no real problems. Just implement the right events that call the
right methods. Maybe instead you want to create a text based interface like
the old RPG, so you could have something like this:

> look around
You see a spring.

> eat spring
You cannot eat spring.

> touch spring
Spring is hard and metallic.

> grab spring
You are now holding a spring.

> move north
You are standing in front of the door.

> drop spring
The spring bounces in front of you, coming to a halt.

> taunt spring
The spring does not respond to your taunts.


And grab, move, and drop springs would simply call functions on your
presenter.

Or on a more serious nature, you could also write automated test cases using
unittest or nose or one of the other automated test tools, which are
invaluable when you want to make sure that your program works correctly.

It takes a little practice to get the hang of writing code that way -
Test/Behavior Driven Development helps - but the payoff of having decoupled
code is quite valuable.

HTH,
Wayne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20111005/1c326b2a/attachment-0001.html>