help building a chain-of-command (or maybe Object Oriented Recursion)

Laura Creighton lac at cd.chalmers.se
Sun May 27 07:51:57 EDT 2001


I think my design might be fatally flawed.  I want to lay it out here 
and see what you think.

I want to use Decorators and to add functionality to basic Tkinter
Widgets.  I want to be able to stack them in any arbitrary order, so I
only have to write the have-scrolling-ability object once, and then
both be able to scroll a text widget that has a yellow border (the
border gets scrolled as well) and put a yellow border around a 
scrollable text widget (the border stays put and the text scrolls
around inside it).  I also want to be able to add my decorators dynamically.
You can put a red border around a black border if you want to.

I think I understand how the method parts should go.  Given a list
['BorderDecorator', 'ScrollDecorator', 'ValidationDecorator', `MyMegaWidget',
 'Tkinter.Entry'] and a method object (say 'resetfield'), I march down from
top to bottom asking `do you know how to do that?'  by redefining __getattr__.
If my __getattr__ gets called, you know that this object doesn't know how 
to do that method, so my __getattr__ should just call apply of list[0]
on list[1:].  {I have just reimplemented CAR and CDR and we can now 
proudly say that there is nothing that you can do in Lisp that you can't
do in python.  It's just a simple matter of programming, <grin>}.

Eventually the method call succeeds, and you go away happy, or you run
out of methods to call.  I don't know what the advantages of building a
DoesNotImplement object and stick it on the end of every such list I
build vs checking to see if list[0] exists, both ideas occurred to me.

If you want your decorators to either do the whole job or forward it
to somebody else, then you are building the Chain of Command.  If you
want them to do as much as they can and then forward what they can't
on you aren't supposed to call it Chain of Command and the Design
Patterns Smalltalk Companion calls it Object Oriented Recursion.  But
the idea is the same.  

But there is a problem. The Scrollbar Widget and the other Widget
that is going to be scrolled really need to know about each other.
To connect a  scrollbar to a widget, you have to set the widget's
(x or y)scrollcommand callbacks to the set method of the scrollbar, and
set the scrollbar's command to the (x or y)view method of the widget.

I don't think that this means that my design is fatally flawed.   But I
don't know how the creational part of this idea is supposed to go.  If
I could make one, I could use it all right but I don't know how to
go about making one.  Has anybody done this?  Or can anybody tell
right off that I can't do this, no matter how much I want to, and I have
to start over again?

Thanks for listening.
Laura Creighton








More information about the Python-list mailing list