Platonos - Platonos Projects - Platonos Application FrameworkThe Platonos Application Framework provides a complete robust pluggable Swing application with which you can use to build your own applications from. By utilizing the packaged plugins, you get, out of the box (or archive, whatever your fancy is), a fairly solid application with a lot of the common functionality most desktop applications have come to have in them. The following bulleted points will outline the primary features of the application framework.
- Core Plugins
A core set of plugins are provided to give the basic UI capabilities of the framework. These set of plugins provide a number of extension points that your plugins will contribute to to add menuitems, toolbar buttons, visual window frames that your plugins can add content to, and more.
- Preferences Plugin
A preference dialog that can be embeded or popped up to display preference options. Other plugins can contribute preference items to this dialog to centralize where users will change options that various plugins provide. The actual storage of preferences is pluggable so that the application developer can decide how they wish to store preferences.
- Help Plugin
A help plugin provides a mechanism to allow plugins to add their own help. Contributing plugins add help that is found within their plugin package. The help plugin is fairly simple, it allows topic based lookups, a search facility and the ability to jump to any topic so that context sensitive help can trigger the help system.
- User Configuration plugin
Users will want to configure certain aspects of the application, such as the the size and location of the main window, locations of internal windows, and so forth. Additional configuration information can be added via more plugins. The purpose of this plugin is to provide a user based save and restore of configuration data that other plugins can contribute to if they provide user level data that may be beneficial to save and restore.
Beyond the above, there is much more to the application framework. For example, you are not forced to use all the bundled plugins. If you have no need to have built in preferences, help, configuration management, various services, etc, then simply don't bundle them with your application. The point of all these bundled plugins is to attempt to provide a robust application framework so that you, the developer, do not have to reinvent the wheel for the more common application pieces. As these plugins are part of the open source framework, you are invited to modify the source if you are not happy with the way they are implemented, either to better suit your needs, fix a bug, or what have you.
The application framework makes use of several of the components found in the Platonos Components project as well. Like the bundled plugins, you may not wish to ship the entire bundle of components. Each component has it's own individual bundle as well as the "super" bundle of all the components. The framework bundle comes with these individual components as well, so that you can decide which components you want to use and which you do not. The important thing about including or excluding certain plugins and components is to make sure you don't exclude a plugin but include a component that is never used OR the opposite, exclude a component and include a plugin that uses the excluded component. In the first scenario, you would merely add "bulk" to your application package, but in the second scenario you would find yourself with runtime problems; however, this is also dependent on another benefit of the application framework (really the way the plugin engine works), that is, if the plugin that uses the excluded component is never used in the application, you will never notice a runtime problem. This can be a double edged sword. If you do not fully test your application, you may get bit when it's in production.
That last bit was leading into another benefit of the application framework. Because it is built up entirely of plugins which are managed by the Platonos Pluginengine, the classes within each plugin are only executed if another plugin makes use of them. While each plugin is loaded and parsed, the actual code is not instantiated until used, with the exception of some plugins that may require immediate initialization. The benefit of this is many fold. Startup times of applications are dependent only on the JVM startup speed and potentially the few plugins that need to initialize upon startup. You could literally have hundreds of plugins make up an application and almost all of them sit idle until used. Most of this use comes from making use of the menus and buttons, but no doubt some plugins will display visual windows that when in use may start up other plugins. Another benefit is resource usage. The less plugins in use, the less resources consumed by the application. Only if a plugin is needed will it's code be executed, and only at that time would resources like images, video, audio, property files, database connections and more would be utilized.
A very important part of any product is its quality. This project is open source thus almost immediately gets the bad wrap of being low quality. Nothing could be further from the truth. One of the authors of the project is a QA engineer that has worked extensively with developing a Swing UI automation harness and framework to test Swing UI applications. Both the original authors believe heavily in the use of unit tests, manual tests and automation tests to ensure the various components of this framework are of excellent quality. Our code is heavily documented to ensure easier maintenance for any who wish to work with it, and while it is an ongoing process, the application framework is continually being tested against automation tests for both the UI and the code itself. The result is (and will continue to be) better quality than most commercial application frameworks, for that matter applications. We can't expect this framework to be widely used if the underlying plugins that make it tick don't tick in unison. If, by chance you come across any problems, please do not refer us back to this paragraph. Testing is an ever long process and in our opinion is never complete. You can test an application in infinite ways, so what we, and anyone else using the framework would be much happier seeing is those of you who use the framework finding bugs, to either alert us to them via Bugzilla, or go into the offending code and fix the issue, sending us a patch. All we ask is that patches include a detailed explanation of what was wrong and what fix was applied.