Hi. Can someone please point me to links and discussion thread for following. I've cascading frames, one calling the other further down the chain : Class A calls Class B e.g. bFrame = new BFrame(x1, y1); Class B calls Class C e.g. cFrame = new CFrame(x2, y2); Class C calls Class D e.g. dFrame = new dFrame(x3, y3); Ideally I would like Class A to be the controller, that is to say, BFrame returns several param-values to AFrame so that AFrame can decide whether to call CFrame and what params to pass on from AFrame to CFrame.
It seems most likely that I need the return method. Silly as it might sound, I need to read up on how to use it. Could some one please point me to reading material. TIA :-)
Your question needs a detailed posing. What exactly you are going to ask is not clear. Give the code where u struck and elucidate the problem. I may suggest u to refer the java tutorial and come to query. U can get the free java tutorial at java.sun.com
(OCEEJBD6, SCWCD5, SCDJWS, SCJP1.4 and Oracle SQL 1Z0-051)
posted 16 years ago
Hi. Thank-you for taking time to look at my issue and the advice to read the Java applet tutorial. It is not coding detail that I'm looking for, rather I was hoping for a general direction or approach. As I see it, there are two choices: (1) a2a commnication making extensive use of public statics, which has its disadvantages; or (2) create a registry class for registering, enabling a2a and destroying applets, which is absolutely shocking for maintenance. Using the AppletContext API is not an option, but please do assume that they have the same codebase and runtime environment. This is to enable a nodal control rather than a chained series of cascading applets, one calling the next in line. I hope I've made it clearer. TIA :-)
I am not sure what you\re trying to achieve either, but here are a couple of points: If you are passing similar data between frames, then that data could be structured as another class. Each frame would have a different instance of this class to individualize the set of returned values. The return statement would simply pass the instance of the data class back the calling frame. You could also have call back entry points in each of your frames for the next frame to call back on. You would pass each frame's instance on to the next frame so the next frame can use it to call the previous frame with values as parameters. If only one frame should show at a time, the others could be set invisible in turn while one frame only is visible at a time. Or .. you could just have one frame with different data class instances and just move the data classes around. So many possibilities! There are many more ....
The nice thing about Standards is that there are so many to choose from!
There are a couple ways to return multiple values. The most crude is to return a collection. This is not too clean because the multiple values are not named or typed and you lose all the benefits of a typed language. It's better to find or contrive a class that will hold what you need to return. For example, if you need to return X and Y coordinates, a Point object would be a perfect return. Kent Beck (if you don't know who he is, google and find out!) made up the name "collecting parameter" for a class that the calling routine passes in, and the called method sets some or all variables. I think he used this to gather values from several places into one object. For example, you could pass in a Point object and the method could modify the X & Y. If that didn't hit your question, let us know.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
I'm a little fuzzy about what you are asking exactly. Perhaps some code from your project, rather than the contrived example, will help clear things up. Posting code will help clear up some of the more specific question I have as well: where are bFrame, cFrame, and dFrame declared? If they are contained within the A, B, and C, respectively, then you simply can return an instance of A which indirectly contains the instances of the other classes. Getting the data where you need it may be a problem, so you may need to re-think your design. Again, I think some more detailed explanation of the project and hand as well as some more specific code will help us answer your questions more clearly. Keep coding! Layne
Thanks for taking time to look at my issues. [u]This is the requirement:[u] AppletA calls AppletB and passes onto B some parameters, like this AppletB appletb = new AppletB(xxx ,yyy, zzz); Now AppletB does some calculations and get some input from the user, then passes these results back to AppletA. [u]Let me re-phrase the questions:[u] Obviously I cannot use return(aaa,bbb,ccc); thats syntactically incorrect. I do not want to use the cumbersome (and unsuitable) getApplet(). So if I want to pass parameter from a helper class AppletB to the calling, super class AppletA, what are my options (assume they all share same codebase and runtime environment) : (1) a2a with public static field, like this disadvantages: * all other applets can see and access public statics; * AppletA starts AppletB i.e. applets not started independent of one another, therefore the self reference won't work, it will always by null
(2) Create a registry class whose only purpose in live is to store references to other applets disadvantage * like this, but shocking for maintenance!
Now registered applets can communicate across frames (and browser, I might add) Something more simple would be ideal, like this:
So far I seem not to have many options, have you got better ideas that you can share with me ? TIA :-)
humanum errare est.
posted 16 years ago
About Kent Beck http://www.cs.uni.edu/~wallingf/patterns/elementary/chiliplop99/submissions/early_oop_patterns.html Some articles seem to hit the spot but the links seem to be broken or the articles not fleshed out - informative non theless e.g. :-) External Patterns The following patterns are not a part of Roundabout but are referred to by one or more of its patterns. Links to on-line versions of the patterns are provided where available. * ?? Caching Temporary Variable (Beck) o Problem: How do you improve the performance of a method, in the face of repeated expression evaluations? o Solution: "Set a temporary variable to the value of the expression as soon as it is valid. Use the variable instead of the expression in the remainder of the method." * ?? Collecting Parameter (Beck) o Problem: How do you return a solution that is the result of collaboration among several procedures? o Solution: Add a parameter to each of the procedures. Use this parameter as a means of passing the current state of the computation among the collaborators.
humanum errare est.
posted 16 years ago
Thank you all for your time and good advice. It works well now, but I'd like to test it first so that the singleton cannot be accessed except by the current thread. :-)
When you say "frame" I assume you're talking about the Swing UI component (as opposed to a "frame" on a protocol stack). Getting UI parts to communicate with each other is always coming up wherever I work, it seems. One outmoded approach that could nonetheless still yield some interesting ideas is InfoBus. It was originally a spec for letting anonymous JavaBeans communicate with each other, primarily for the purpose of letting them discover each other in an applet and learn how to play together. Another interesting approach, and one that I think is probably the best I've seen, is to let the UI remain as dumb as possible...it can simply be given new data and told to refresh. The neat innovation I saw here was, every single data change in the model caused a refresh request to be sent to a refresh mediator. The mediator simply waited a few hundredths of a second (configurable amount of time), and if another refresh request didn't come in, it'd execute the refresh which would cause a complete display update based on a declarative mapping from model components to UI components. This mediator's sole purpose in life was to prevent a hundred refreshes from being executed one after another in the space of a short time, causing the display to flicker wildly and the user to go into epileptic seizures. Later on we added a finer level of granularity to the mediator--it could refresh individual UI components based on intelligent analysis of whether their content changed. It worked quickly and the display was never behind the model by more than a couple of milliseconds...very slick, and simple to boot. sev