Home > Archive > Software Engineering > May 2006 > architecture for gui status bar messages
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
architecture for gui status bar messages
|
|
| timasmith@hotmail.com 2006-05-07, 10:05 pm |
| 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
| |
| Oliver Wong 2006-05-07, 10:05 pm |
|
<timasmith@hotmail.com> wrote in message
news:1146855860.955064.17260@y43g2000cwc.googlegroups.com...
> 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...
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
| |
| Phlip 2006-05-07, 10:05 pm |
| 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".
--
Phlip
[url]http://c2.com/cgi/wiki?Z Land[/url] <-- NOT a blog!!!
| |
|
|
timasmith@hotmail.com wrote:
> 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
| |
| timasmith@hotmail.com 2006-05-07, 10:05 pm |
| Yes, yes of course !
That feels completely right.
thankyou
Tim
| |
| Chris Uppal 2006-05-07, 10:05 pm |
| Phlip wrote:
> 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
| |
| Phlip 2006-05-07, 10:05 pm |
| Chris Uppal wrote:
>
> "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.
--
Phlip
[url]http://c2.com/cgi/wiki?ZLand[/url] <-- NOT a blog!!!
| |
| Chris Uppal 2006-05-07, 10:05 pm |
| Phlip wrote:
> 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
|
|
|
|
|