What means "small Swing application"

One specificity of this project is to be targeted at small swing applications.

"Small application" means a swing application where all the GUI can reside at the same time in the memory. So, for example you can preload all the resource bundles containing translations strings, you can instantiate all the screens (panels) composing the main window at startup, there is no multi-window component.
A "Small application" is typically single-task. it means that if a dialog is opened, it will be modal. Similarly, the asynchronous task support is there to avoid blocking the GUI and have a good on-the-fly GUI view of the task progression but not to launch and execute a set of tasks in parallel.
In a small application, the modularity is limited: the initial application builder knows all the application parts.

This is a typical framework for single-person home application or small control GUI. This limitation has been chosen intentionally to keep the framework simple and intuitive.

Frameworks for bigger applications requires lazy instantiation (because you cannot load everything at startup) and strong modularity (because reducing coupling is mandatory to have a maintainable application). It means a lot of discovery/factory plumbing that makes the framework more complicated. All that is overkill for small applications (but mandatory for big ones). A good swing framework for big applications is the Netbeans Platform (TODO: ref).

You can also use this framework just for learning purpose. It is an example of how swing can be used in a consistent way. Of course, as this project is open source, you can use only parts of it or make it evolve to something better fitting your needs.

Project structure

The framework is divided in two projects sfac-utils and sfac-core.

The first project contains all the classes that have to be known by the business tier (or layer) of an application. The second one contains objects that are specific to GUI.

This separation allows you to clearly demarcate what is the GUI (or view) from what is the business (or model) -- one aim of the MVC pattern. For big projects, I always advocates that the model and the GUI are in separated projects. it allows, by defining correctly project dependencies, to ensure that the model is totally independent from the GUI. For small projects (like the projects targeted by this framework) this is less a necessity but I kept it for clarity and educational purpose.

So to be simple:

• Your model classes can only use the classes from sfac-utils.
• Your GUI classes can use the classes from both sfac-utils and sfac-core.

Note that the multilingual support is on the "model" side. While, most of the time, internationalized string are strictly a GUI matter, most of my projects have a simple "report" capacity. Reporting is a "model" or "business" functionality (I'm speaking of the core task, not the GUI to control it) that also needs translation if you want to produce reports in specific languages. So, keep in mind that the calls to LanguageSupport should always been done from GUI unless you have a good reason. A good reason being that you have a business task (like producing a document in a specific language) needing LanguageSupport.

Framework requirements

What do we expect from a GUI application:

• That it has the common look and feel of a GUI application. The application should conform to the usual patterns of the user OS. In particular, it should have menus and toolbars that behaves consistently with the OS recommendations. For example: the same user actions can be triggered by various means: menu bar, tool bar, right-click popup menu, accelerators, shortcuts...
• That the application interface is translated in the user language.
• That the application reminds some setup made by the user the next time it is open. In particular, when GUI objects (like windows, table columns, split panes... ) are resized to display correctly in the user screen, the application should remind those settings.
• That the GUI doesn't block and look buggy when doing a time-consuming task. It's doesn't mean that the user can continue to work in the application, but that the application should repaint correctly and display the status of the executed task.
• That it is packaged and can be installed easily.

  Swing offers basic support for some of those requirements (ex: bundles for translations, swing Actions, frame with menu and toolbars, swing worker... ) but doesn't say how to organize to eventually provide a running application.

  The swing framework proposes inter-operable solution for all those concerns.

Framework content

This framework proposes solution for following concerns:

• Main frame building and display.
• Action management: How to make menus, toolbars, popup menus, shortcuts that uses the same swing actions
• Settings: how to store and retrieve user settings
• Application state: how to restore the application in the state it was left in (windows size, sorting, components positions ...)
• Internationalization: how to implement an multilingual application. This framework allows to dynamically change the language without restarting the application.
• Look and feel: How to leverage the look-and-feel modification capabilities of swing.
• Error Reporting Strategy: How to manage errors and report them to the user.
• Application packaging: how to arrange the various batches, jars, resources, configuration files ... into one running application.
• Asynchronous tasks: How to implement simple 'background' task without blocking the GUI.

Of course for each concern, the framework proposes a solution (and not the solution). The best I can say is that the proposed solutions target simplicity (of development, usage and maintenance) and proved working well together in practice.

The framework comes with some documentation and can be used simply to learn swing trough the proposed examples.

There is also an example project (TODO) of a "hello world" application that can be used as a template to start your own application.