I am about to refactor a Swing application from using ActionListeners to Action classes because I realized that a lot of my menu items are going to be used in a toolbar as well.
Right now I have a class called ImportExport which deals with the state of the underlying model and then displays the appropriate user dialogs. ImportExport has the functions save(), saveAs() and open(). When a user clicks on the “Open” menu item, the action listener calls open(), open() first checks if the model has changes and if that’s the case displays a dialog asking the user if he wants to save first. Now if the user clicks “Yes” open() calls save() which again performs some checks and displays user dialogs. save() is pretty persistent: The only way to get out of this action is either by saving successfully or the user deciding that he wants to cancel. I strongly rely on the feedback that save() provides and if a user wants to cancel I also cancel the calling open() function.
I wanted to split up the ImportExport class into three classes (OpenAction, SaveAction & SaveAsAction), each of them subclassing AbstractAction and eventually get rid of the ImportExport class. And this is where my problem arises: How do I tell the SaveAction to execute if the user wants to save the model before opening another one? And how do I get feedback if the user decides to cancel?
Is this even the right approach? I don’t like to have duplicated code in the save and open action and I have already put as much functionality as possible into my underlying model but user dialogs are obiously out of place there so this is no option. Was Action designed at all to hold this kind of functionality or sould I just keep my ImportExport class and simply delegate all action calls to the appropriate functions in ImportExport. How do you use Actions?
I sometimes add a ‘controller’ action when there is a decision tree involved. OpenAction, SaveAction and SaveAsAction would subclass this controller Action. The controller action would determine the state of the model and request more info from the user if appropriate and then call the correct subclass.