Designing an application so extra comopnents can be added later

Question

Hi all
I'm about to start designing a new application, but would like to design it in away that I can add new modules at a later date without me having to alter the existing app.
Basically these new modules will be small apps that will do there own thing, but will be fired from the main app, and when they are closed you return to the main app. So after a while I will have an application with loads of seperated modules which will be optional for the user to add when installing the app depending on whether they need them.
I was thinking of having some sort of add/remove module dialogbox which will allow the user to select a new module to add or remove etc. But what is the best way to design the app so that these modules can be added. Do i use the class loadder to load the classes dynamically at runtime or develop the modules as seperated programs and fire them up from main program as needed?
Any ideas would be great.
Thanx
Gerard

Answer 1

Hey,
First off, I don't know if I stated it wrong earlier, or perhaps I am not understanding what you mean, but my UI framework has nothing to do with eclipse at all. It is built around my plugin engine and Swing, completely. It has no outside dependencies other than my plugin engine, the rest is all JDK (thus far). The engine itself has a embeded xml parser, that is it. It doesn't rely on any logging api, or any other outside api. So using my UI framework is thus far all wrapped around the JDK API.
Can you elaborate a bit more on what you mean by allowing a specific mandatory list of plugins, and optional? Should an application specify required plugins, then anything else found in some dirs are loaded after that? I ask this because a dilema I am running into with my UI framework is how to apply menu items in a certain order. My engine does not load plugins in a specific order or priority, first come first server as they are found. Problem is, if one plugin adds a QUIT menu item, and another an OPEN item, and OPEN appears AFTER QUIT because it is loaded after the plugin that provides QUIT, it looks wrong. So I am sort of stuck right now on how to allow plugins written by different people to build a solid menu tree without an inconsistent structure. We wouldn't want Help on the left and File on the right, but that is possible right now with my UI framework. One thought was to make my UI plugin set up the basic menu structure, with File -> Open, Save, Save As, and Exit, and a Help on the far right, and anything else gets added in between. This would be partially ok, only that some apps may not need a File menu, or a Help menu, so I don't want to enforce this behavior.
I am also not sure I understand what you mean by a plugin specifying requirements? Can you elaborate a bit more on that? Maybe give an example, something you may already do with your code?
Finally, some good ending points. I agree the end result is what the client wants, assuming the app you are working on is for a client. I also see where a pluggable architecture appeals greatly to a development community, such as in the case of Eclipse. 90% of the recipients of plugins are developers themselves. Naturally, it being a productivity tool for developers, this makes sense. But having worked with audio applications that are also heavily plugin centric, it seems to me a lot of clients are well aware of what plugins are and how to obtain them for their needs. What I am saying is that while the end result may be that a client doesn't much care about the concept of a plugin, just that it works, there are plenty of cases where client applications are heavily plugin centric and would require some knowledge of what a plugin is, how to obtain updates, possibly how to turn them on/off, add/remove, etc. Perhaps in some cases these types of tasks are higher level, such as turning on an FX option in a photo program may actually load the plugin, without the end user realizing they are dealing with a plugin.
At any rate, I thought I said, but if not, I in no way was trying to imply what you have done is "easy". No doubt you have spent a lot of time developing and know what you are doing. I guess my focus is the underlying manner in which my engine handles plugins. It is more like a servlet or ejb container in that it provides a number of services for plugins to use and maintains a number of things so that plugin developers don't have to worry about it.
At any rate, I appreciate the continued correspondence. I would enjoy your looking at what I have done, check out the source, taking it for a spin, see what you think. More eyes are better, and hopefully offer more ideas, better ways of doing something, etc.
Thanks.