Hi,
Yes the GOF "Patterns" book is wonderful, I have got little bookmarks all
through it!
I'd definitely like to hear of any good links or pointers on this (oop
thinking in wxPython)
- I am still getting my head round gui programming in general, and now
would probably be the best time to lay down good habits. Or, at least, not
lay down too many bad ones. 
I am particularly confused by event-handling.
I have recently read about the "eventManager" class that is in the demo for
wxPython 2515:
"""EventManager:
The goal of the EventManager is to make wxWindows events more 'Pythonic'
(ie. object-oriented) and easier to work with, without impacting
performance. It offers these features:
Allows any number of listeners to register for a single event. (In addition
to the standard wxPython feature of a single listener being able to respond
to many events.)
Makes it easy to disconnect and reconnect listeners. This has the effect of
reducing the need for case-based branching in application code.
Has an object-oriented API. Programmers register to get events directly from
the objects that generate them, instead of using ID numbers. """
I think that this way of doing things may make more sense to me, I find all
this messing about with IDs and so forth to be entirely bewildering.
I was wondering if many people are using this newer method yet, and if they
have code examples I could look at?
For Janos: I have been recently starting to learn wxPython myself, and I
have just gotten to the point
where I was starting to think about overriding some classes and so on, and I
found the following to be very helpful.
They are mostly from the "Recipes" or "cookbook" section of the wxPython
wiki, which is at
wxwiki.python.org
I have started by listing the ones that start with the basics, like best
practice in overriding basic controls, how to make them fairly reusable by
other programmers (which also includes yourself in a couple of months of
course, when you have forgotten why you did it that way!)
- what methods you should over-ride, how to catch events, and what the
"signature" of a derived control that you make should be like in order for
it to be familiar to other wx programmers, and this kind of thing.
Then is some stuff on "two step creation". If anyone could explain this to
me I would be thrilled! I have read that it is useful in order tobe abel to
set "Extended flag information", but I have no idea what that really, means,
and why you couldn't just do that in, say, a perfectly ordinary "init"
method??
Then finally, Bill Bell's very intersting example showing how to use
validators and oop to build "data aware" controls for things such as
interacting with databases. This really starts getting a lot more complex
(complex! I said Complex! *Not* Complicated!!!), and using factory classes,
mixin classes, and the new(ish) python metaclass hacking ( I think that's
what it is. Actually I'm not really sure, as I barely even know what that is
yet, all I know is he does some stuff there that I don't understand at all
but that looks pretty groovy, so I assumed it must be "metaclass hacking" 
···
##------------------------------------------------------------------#
#Unit Testing Using wxPython: I haven't tried this out, but since someone
has mentioned
#Extreme Programming, and unit testing is so foundational to that, I thought
I would stick
#this link in right at the start where it belongs! ( My own not having done
it yet not-with-standing!)
http://wiki.wxpython.org/index.cgi/RecipesEngineering
##------------------------------------------------------------------
#Here's some guidelines on creating custom controls derived from existing wx
ctrls, the classic OOP technique:
"""1 Building ControlsCreating new wxPython windows is a simple task. You
override a few methods, maybe catch a few events and your class does what
you want it to do. You can distribute this new "control", people can use it,
life is good. What this document attempts to describe is how to go beyond
the basics of a functional window into creating a reusable control.
It should be noted that this document is describing "best practice" as
understood by the author, rather than current practice as exemplified by the
wxWindows developers. Certain of the built in controls provide
counterexamples to the advice here. """
http://wiki.wxpython.org/index.cgi/BuildingControls
#------------------------------------------------------------------#
#Some other things you may need to override when making new controls, in
this case things to do with the sizing of #the widgets.
#I am just about to start thinking about these sizing issues on my widgets,
so I have been ferreting our information.
#
#I just found this in the "migration guide"
#for moving to wxPython 2.52.x. I'm using 2.5.1.5 currently but I guess I
will upgrade now, *before* I start really #thinking hard about sizing
issues, so that I am using the newer conventions from the start.
"""In order to fit well with this new scheme of things, all wxControls or
custom controls should do the following things. (Depending on how they are
used you may also want to do the same thing for non-control custom windows.)
Either override or inherit a meaningful DoGetBestSize method that calculates
whatever size is "best" for the control. Once that size is calculated then
there should normally be a call to CacheBestSize to save it for later use,
unless for some reason you want the best size to be recalculated on every
layout.
Note: In order to successfully override DoGetBestSize in Python the class
needs to be derived from wx.PyWindow, wx.PyControl, or etc. If your class
instead derives from one of the standard wx classes then just be sure that
the min size gets explicitly set to what would have been the best size and
things should work properly in almost all situations.
Any method that changes the attributes of the control such that the best
size will change should call InvalidateBestSize so it will be recalculated
the next time it is needed.
The control's constructor and/or Create method should ensure that the
minsize is set to the size passed in, and that the control is sized to a
blending of the min size and best size. This can be done by calling
SetBestFittingSize."""
http://www.wxpython.org/migrationguide.php
#------------------------------------------------------------------#
#Creating a Collection of Controls
"""This recipe shows how to create an aligned column of buttons on a panel
by creating the buttons as instances of a nested class. """
http://wiki.wxpython.org/index.cgi/CreatingCollectionOfControls
#------------------------------------------------------------------#
#Two-Stage creation of window objects
"""wxWindows supports doing a 2 stage creation of window objects, which is
sometimes necessary for setting extra flags or for class factories like XRC.
Since C++ allows overloading of methods (including constructors) it is
fairly easy to precreate an instance of a window class and then call its
Create method later. But in Python the constructor that is wrapped by
__init__ is always the one that does the creation too.
It is possible to do 2 stage creation of window objects in wxPython, it's
just a tiny bit tricky. All of the classes have a special factory function
that precreates the object, and then you can later call the object's Create
method to do the 2nd stage, (or let XRC or whatever do it for you.) The
factory is always the same name as the class, with "Pre" inserted in it,
like wxPreWindow, wxPreFrame, etc. """
http://wiki.wxpython.org/index.cgi/TwoStageCreation
#------------------------------------------------------------------
#Data aware controls and validators
#This recipe has an extensive listing which displays oopy and "meta" oopy
things like the use of mixins,
#funny methods with underscores in their name, the "property" builtin of the
newer versions of python,
#which is to make some of the darker magic a little more convenient, and so
on. I would love to get my
#head around all this some time!
#Perhaps if you are looking at it, email me and we can explore it together!
"""wxPython provides an excellent and growing collection of controls, with
means for sizing, aligning and otherwise manipulating them.
When one builds an application that populates controls with data from a
database one needs to make the controls data-aware, which is to say, one
needs to make the controls capable of responding to database state changes
and also of responding to requests from the database about whether a
database field value should be changed, for instance. At the same time, the
database needs to be able to update its content from the controls, at the
discretion of the user.
This topic shows:
a mixin class that makes single controls such as edit boxes data-aware; a
factory that creates data-aware controls from wxPython controls using the
mixin.
a factory that generates datasource classes capable of mediating between the
data-aware controls and databases.
sample datasources created using this factory for use with MS Access and
MySQL.
a factory that generates validators that can be used with other elements of
this system, and with the state machine-based validators discussed in other
recipes in this collection.
sample validators created using this factory for use in checking Canadian
postal codes and integers.
a class that assigns friendly names to database fields, as well as other
information, in co-operation with the other machinery described here.
a sample wxDialog subclass that illustrates applications of the above. """
http://wiki.wxpython.org/index.cgi/Data_2daware_20Controls_20with_20Validato
rs_2c_20demonstrated_20in_20a_20dialog
-----Original Message-----
From: Xavier Spriet [mailto:xavier@eliquid.com]
Sent: Saturday, 14 August 2004 07:10
To: wxPython-users@lists.wxwidgets.org
Subject: Re: [wxPython-users] Building OO GUI
I have also been looking for some good documentation on the subject of
best-practise programming with wxPython that is targeted only at
wxPython developers.
I'd love to hear more on that subject.
Thanks,
Xavier
On Fri, 2004-08-13 at 16:56, Barry Scott wrote:
> The GOF book is great, also read the Anti-Patterns book and learnabout
> Extreme programming.
> As suggested MVC can help with complex problems. But if you need a
> GUIfor a simple problem
> then its over kill. Avoid the Java problem of death-by-objects.
> Keepthings as simple as you can.
>
> Barry
>
>
> On Aug 9, 2004, at 10:44, janos.juhasz@VELUX.com wrote:
>
> Hi All,
>
> I am just studiing designpatterns of GOF.
> It is a very interestingtheorethic work, that is very
> practical.
> I am just looking for somesimilar docs about how to write GUI
> application with wxPython on theOO-way, (like best practices).
> All the samples in thewx.samples are very usefull, but they
> can show mainly the technicalthings about using diferent
> controlls.
> I am interested about howcan I separate the GUI and the
> business logic and how should I manageit.
> I also intersted how towrite database handling applications
> with wxPython.
>
>
> Could anyone recommend anygood docs on it?
>
> Yours sincerely,
> ______________________________
> János Juhász
--
Sincerely,
Xavier Spriet <xavier@eliquid.com>
IT Director - eliquidMEDIA International Inc.
(tel): (519)-973-1930
(fax): (519)-253-0337
(800): (800)-561-7525
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org