Platonos - Platonos Projects - Platonos Application Framework

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


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.

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

Lazy Initiation
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.

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