Bug #3147
closedGet rid of Swing componets in Ecogrid data access classes
0%
Description
Here is an email from Matt:
Jing,
I noticed you're having difficulty with calling the ecogrid data access classes from within JUnit tests. This illustrates an
underlying problem in the implementation -- that it depends on GUI classes -- that would also surface when running kepler in headless
mode on the command line or behind a web interface. Rather than calling JOptionPane directly, you should probably be callinga
mediator class like ptolemy.util.MessageHandler that can be configured to do different things depending on whether it has a GUI
available or just stdout available. This design follows the basic Mediator pattern and would help in improving the overall design. I
think anytime you are instantiating Swing components in an actor we are possibly limiting the execution environment of the actor.
Can you factor out these alerts so that the use the mediator pattern?
Matt
Updated by Christopher Brooks about 16 years ago
Actually, calling MessageHandler can result in problems, especially anything
that requires an answer, such as yesNoQuestion() and yesNoCancelQuestion().
It is usually better to throw an exception for problems than to ask the
user if they want to proceed, or to properly set the default behaviour
One use of yesNoQuestion() that seems to come up fairly often is whether a
file should be overwritten. I've found the best thing is to have a parameter
"overwriteFiles" which defaults to true. Otherwise, the user is bombarded
with dialogs.
Updated by ben leinfelder about 16 years ago
I believe this is fixed. There was spot in the EML actor that was using Swing directly, but I replaced that with MessageHandler. Jing did this with some other classes, too.