James Edward Gray II wrote: > On Feb 10, 2004, at 3:29 AM, Gary Stainburn wrote: > > > Hi folks, > > Hello again. > > [snipped history] > > > One of the points made in the previous threads was that there should > > be no > > need for sub-classes to have a link back to it's parent, and through > > the > > correct splitting of functions (inter-instance in class, intra-instance > > within container) I've done this okay. > > Let's not say you should "never" have links back to the parent object. > I've seen places where it made fine sense. I actually have I server > I've been working on that does this. Individual connections keep a > link to the main server, to inform it of changes in their status, based > on network reads/writes and to access server wide functionality, like > logging. > > Generally though, what you say is a good rule of thumb. > > > My problem is now: > > > > I need to be able to pass to the Trainset instance a ref to a callback > > within > > Program (to refresh a PerlTk window, or to send a signal to a model > > railway > > controller). This callback then needs to be triggered by the Trainset > > instance itself, but also from Signals, Gantries, and Tcbs. > > I should warn that I have no familiarity with TK, though I do have > general GUI toolkit knowledge. > > The above sounds backwards to me. Why should Trainset objects be tied > to their interface? That limits their usefulness. The interface is an > interface for representing Trainset objects, right? Well, then it > makes sense for that interface to maintain a link to the Trainset > object it is currently representing, right? > > I assume TK is event driven. So, when an event happens, I would think > you would access the Trainset in the event handler, make changes and > update. > > Now, if the Trainset object is somehow being modified by an outside > source (the model controller you mention perhaps), things get a little > trickier. You could always poll the Trainset object every so often to > see if it has changed. Polling is generally considered bad though, so > possibly better would be to have the code that is somehow changing > Trainset, to call an update routine on the interface. If controller > signals are just another event being handled by the interface and the > interface is already keeping track of the Trainset, as I believe it > should, the controller event handler can pass along the change and call > for a refresh. > > Be aware, if the GUI allows changing the Trainset and the model > controller is changing the Trainset, you make have concurrent access > issues to deal with. > > Well, maybe that will give you some new ideas. > > James
When I use Tk to describe an object sytem, I usually make an application-level object, aware of both the object system and the Tk interface structure, to control the overall process. I also make wrapper classes for each major component widget, to manage its role in the overall process. These application-level classes assume the responsibility for being aware of the various classes and objects used. Therefore the conceptual classes used to model the problem need not be aware of any extraneous factors. They simply need to provide dependable performance at their own interfaces, to model their own concepts faithfully. So far, this approach has worked pretty well. I am able to make major, radical changes to individual sections of my program, with minimal impact on other sections. Joseph -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
