VisualMust
 
VisualMust® software
Written entirely in the Java(tm) programming language.
 
 
VisualMust Architecture

Source code Architecture

Any application offering a Graphical User interface may be conceptually split into three main parts :

The GUI construction (all the code needed to declare the various visual components of it, set their attributes like color and position, their initial status (enabled, visible), aso...

The «active» code which, in fact implements the functionality of the application and is the jewel located in the box (the GUI)

A sort of glue that will reflect the user's actions on the GUI to the active part. (Visual programming books call this glue «event processing»).

The active code is what you will have to do by yourself, because we think that any tool that will try to understand your desire will be wrong at a time or another. VisualMust will do strictly nothing for you in this area.

The coding of the GUI declaration, on the other hand is (if not quite difficult) at least boring to write with a plain text editor while it can be fully automated by the use of a visual editor like the VisualMust Interface Builder allowing you to put any visual component at any place and to set any of its properties to an acceptable value. Note that, as VisualMust applies in real time any modification you want, you can, within the interface builder itself, experiment with one layout or another for example.

For the handling of the events, the java conceptors have grouped them in the so-called interface and, in for the vast majority of them, they've also designed the so-called adapters that save you the hassle of coding dummy routines for the events you've decided to ignore. Alas, just because our world is not a perfect one, there are still cases where you may be forced to code some dummy methods. Here also, the VisualMust Interface Builder will be of some help as it will, if it is necessary, code the missing adapter under the cover.

From the preceding analysis, we can consider that you, the real programmer, are mainly interested in the active code (as defined previously) and in the methods needed to respond to the events you have specified. All the other lines (that may for some if not all applications be more numerous) are of less interest. VisualMust tries to reflect this conception in the files it produces. By using the name (xyz) you gave to your application, it generates three files :

The xyz.ODB file holds all what you said to the interface builder and is in a VisualMust specific format.

The xyz_abstract.java file holds all the java code needed to declare the GUI and if necessary the adapters that were needed. It declares in fact an abstract class (hence its name).
Don't forget that this file is just the translation in a form that is acceptable for the java compiler of the contents of the ODB file and that it is simply just recreated from scratch every time you use VisualMust to refine your GUI or your application. If you put anything in it, it will be discarded without any warning someday or another.

The xyz.java file holds the «active» code and is mainly yours. VisualMust will only put in it the methods required by the java architecture and the skeletons of the ones that will handle the selected events to declare, technically speaking a class that will extend the abstract one declared by the previous file. In order to help you in documenting your masterpiece, all the VisualMust generated methods (even the empty ones) will be associated with comments, conforming to the javadoc conventions.
You are completely free of reordering the methods, removing the javadoc comments, adding methods or classes, the only restriction being that the entry points of the VisualMust generated methods must be kept in this file : If you decide afterwards to ignore some event, go to the Interface Builder and deselect it. This will clean up this file and the other too.
It is perhaps necessary to emphasize that, as this file extends the definition of the abstract class created by VisualMust, you may enhance any of the methods declared in the xyz_Abstract file by overloading it. More, you may find in this file some general use methods you may also use in your application.


Project Architecture

All the Interface Builder definitions are stored into a file having «.ODB» as an extension. VisualMust will use the name of this ODB file to generate Java files as well as the Abstract file. VisualMust lets you free to decide on the architecture of your application. You may use a single ODB file or multiple files for your project. With the interface builder, you may create multiple windows, multiple components within the same ODB file, or simply decide to create one component for an ODB. Each ODB will cause a main class to be generated. VisualMust allows you to choose the type of the main class : it may be a bean, a window or a pool of components.

For multi-developer applications, it might be interesting to create an ODB that would contain different components used by the other developers. These components may be windows for logo, popup menus, aso... Of course, all these components may be beans, but creating beans is not always necessary, you may just want to put them into an ODB. You may read an example in the Frequently Asked Questions chapter.


External Classes

In your source code, you may of course use external classes, defined in another source code. The Java compiler provided with JDK(tm) is clever enough to determine dependence and recompile the different source codes if needed, as far as it is able to locate them. For this reason, you are recommended to put your «.class» into the same directory as your «.java». But it does not mean that all your «.java» must be in the same directory, they must be in accordance with the package name, if you are using this facility.