On Wednesday 11 Feb 2004 2:54 pm, R. Joseph Newton wrote: > 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
I have decided to have limited links to parents, where appropriate. For example, a signal must be attached to a gantry, the state of the gantry being the sum of the states of it's signals. It therefore makes sense for the signals to be able to pass on the state change to the gantry object. The gantry can then perform a similar action with the Trainset object, and this call the callback method in the main program. I plan to follow a system similar to what Joseph has suggested. I plan to develop Trainset::Tk, which will know how to represent a signal gantry as a group of Tk widgets. Likewise with lever, TCB sections etc. I can then simply use a callback method within Trainset::Tk from within the Trainset instance. This idea I think tidies things up tremendously. I can understand the point that James made, in that the update of the Trainset objects is being made by a Tk event trigger, and could therefore simply update the screen at the same time, e.g. clicking on a lever throws a signal *and* updates the screen. The problem is that it's not allways possible to know every object that gets affected - the state of the signal may affect other objects, such as changing a locomotives state from 'Stopped' to 'Clear To Proceed'. This is the reason behind needing the callback method. The other problem mentioned, that of concurrent input from the screen and from a model railway controller hopefully won't be a problem. Again, I plan on developing Trainset::Controller, which will be used to both send commands ands receive feedback. The plan is to have this call a callback method similar to the one above. If it does become a problem (I won't know until I start looking at the interface method, possibly standard serial connection), I will look at POE but as I said before, I don't want to add to the complexity of the project until I have to. The way I'm designing it, I think POE could fairly easily be slotted in at a later date. Once again, thanks to everyone for their suggestions. -- Gary Stainburn This email does not contain private or confidential material as it may be snooped on by interested government parties for unknown and undisclosed purposes - Regulation of Investigatory Powers Act, 2000 -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
