architecture for gui status bar messages

[timasmith]

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]

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]

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".

 

[Ed]

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

 

[timasmith]

Yes, yes of course !

That feels completely right.

thankyou

Tim

 

[Chris Uppal]

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]

"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.

 

[Chris Uppal]

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