 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / May 2006architecture for gui status bar messages
Hi, I have an app (Java not that is too pertinent) which is a fat client GUI with a main form, numerous dialogs, wizards, menu actions, toolbar functionality etc. I am looking for a consolidated method for reporting errors. I already have code to log the exception, warning, error etc to a local circular file. But I also wish to display an error message to the end user to indicate a problem occurred. I can't stand a popup error message. Rather I would like to do something similar to Internet Explorers active x warning message, where a bar subtly rolls up with a warning icon allowing you to click for further information. While I do throw Exceptions up and up as far as I can - there are many places, such as within a custom control where I trap the exception early. So to get the interaction with the main frame (or a dialog) should I really pass JFrame or JDialog references throughout my code - or should I use the good old global variables...ew... thanks Tim > Hi, > [quoted text clipped - 22 lines] > really pass JFrame or JDialog references throughout my code - or should > I use the good old global variables...ew... The OO version of a global variable is a Singleton. You could have a Singleton which acts as a model, for which one of the fields of that model is the error message to report. Various controls would act as views of the model, and display the red bar as appropriate. - Oliver timasmith wrote: > So to get the interaction with the main frame (or a dialog) should I > really pass JFrame or JDialog references throughout my code - or should > I use the good old global variables...ew... You are correct to not want the business side to depend on GUI variables. So you need to invert a dependency between the business side and GUI side. Research the "Dependency Inversion Principle", then apply this recipe. The business side modules contain an interface to a "StatusThing". (We don't say "StatusBar", to symbolize our decoupling. We could have another GUI with a StatusBalloon, or a StatusBaboon, or whatever.) A class in the GUI Layer inherits this interface. Pass the interface into the business side, and pass it around as a reference to an interface. At status time, call the interface's setStatus() method. The GUI Layer will localize and display the status message. In this pattern, the business module says "If you want to use me, you must implement this interface, so I can call it when statusses change".  SignaturePhlip http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!! Yes, yes of course ! That feels completely right. thankyou Tim > The business side modules contain an interface to a "StatusThing". "Application status". (The object itself being an instance of ApplicationStatusModel, or some such name.) -- chris >> The business side modules contain an interface to a "StatusThing". > > "Application status". (The object itself being an instance of > ApplicationStatusModel, or some such name.) Let's consider three layers. They usually exist, and are often latent: - GUI Layer - imports GUI Toolkit identifiers - Representation Layer - translates logical to GUI concepts - Logic Layer - the backend; what the application really does In this system, classic MVC lives in the Representation Layer. The View is GUI-facing, yet it could use no GUI Toolkit identifiers. The Model is Logic-facing. The View could implement my StatusThing interface, and the Model could pass it into the Logic Layer. Then that could pass the StatusThing reference to anywhere in the Logic Layer that has a status to report. I suspect this system would run out-of-band with regard to the usual data paths between the Logic and Model. The status message could report any kind of exceptional situation. Another design to consider is of course the Observer Pattern. The status bar observes any number of registered targets in the Model. SignaturePhlip http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!! > Let's consider three layers. They usually exist, and are often latent: Like the fairies at the bottom of the garden ? ;-) > The View could implement my StatusThing interface, and the Model could > pass it into the Logic Layer. After reading this (and the rest of the post) about 8 times, it finally clicked that you are thinking of this the other way around from me. Your "status thing" is a data sink into which the model dumps status information without knowing or caring that it might end up in a GUI somewhere. That makes sense, but -- as it happens -- I was thinking of: > Another design to consider is of course the Observer Pattern. The status > bar observes any number of registered targets in the Model. -- chris > Hi, > I am looking for a consolidated method for reporting errors. I already > have code to log the exception, warning, error etc to a local circular > file. > thanks > > Tim A minor aside on the other two excellent answers: have you looked into MVC? In MVC you'll have a View interface, which will no doubt contain a showError() method, which the controller and model will call whenever something's gone arseways. The point being: there'll certainly be no JFrames or any such GUI-shenanigans in the model or controller; they'll just call this method with (perhaps) text; the view package (via the View interface) will control whether to flash something on the status bar, pop up a dialog, launch a flare, etc. The point being (recursively): with your view encapsulated from your model and controller, then you'll have more freedom to choose the means of error reporting with minimum impact on the rest of you code. .ed -- www.EdmundKirwan.com - Home of The Fractal Class Composition Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.