Abstract: NPI-Builder is a code-free programming language that facilitates the design of Graphical User Interfaces (GUI) that are completely interactive with the users. It is based on the concept of Data Flow Programming used in languages such as National Instruments' Lab ViewĘ and has the potential to become an extremely powerful tool for Engineers and Scientists, as well as Business people, who have a real need to program but no time to learn the intricate and somewhat useless details of syntax and grammar in today's powerful programming languages: C, C++, Java, etc.
We have created the foundations for Builder in a prototype of the language. Because Builder was written in Java (an object oriented programming language) it is composed of classes that are organized in a hierarchy that ranges from the more abstract concepts of the system to the more concrete components or "modules" of the language. We have created the abstract classes that serve as foundations for the language, and have also produced a few of the "Modules" that correspond to the most often used GUI components: Text Fields, Pull-Down Menus, and Buttons.
We have also developed an API (Application Programming Interface) for the continuing development of Builder; and we have produced the guidelines by which Builder can be expanded to fulfill some intermediate goals before becoming the powerful language that we anticipate it can become.
Introduction: The language is based on the connectivity of modules that have specific purposes, and data signatures. Each module has an icon representation on a data-map that represents the input, output or filtering of data, that takes place in that module. Some modules have a GUI representation as well, which forms part of the interface that the final user will interact with. Other modules have functions that don't need a GUI representation.
While "programming" the interface, the user moves icons around on a data-map and connects them with "wires" or "tubes" that will carry the data from one component to the other. At the same time, the user has the flexibility to drag the GUI components on a separate window to "design" the interface as he/she programs it.
An elaborate example that explains how to use the current version of Builder is included in Appendix I, "Users Guide", and can also be found on our server by selecting "Builder" from the menu:
http://www.jwave.vt.edu (a Java enabled browser is necessary to run Builder).
Installation: Builder is a Java Program that can be run as an Applet. You can run Builder as an Applet by simply going to our website:
http://www.jwave.vt.edu (a Java enabled browser is necessary to run Builder)
and selecting Builder from the menu. Then pressing the "Run Builder" button.
If you want to access a copy of Builder on your own server you will need to install Builder.
Note: To run Builder from your server you need a server that can serve Java Applets. To Install Builder:
API (Application Programming Interface): Builder has several core classes that define abstractly some of the basic functionality of the modules and their parts. These classes are: Moveable.class, Node.class, Icon.class, and Wire.class. There are several classes that implement some of the basic GUI components available in most interfaces: ButtonNode.class, PullDownNode.class, and TextFieldNode.class; and there are classes that define the interface of the Builder Editor: Builder.class, Map.class, ToolBar.class, MyFrame.class, and StartApplet.class.
There are also a few additional classes that support these classes and take care of some details of implementation: the different Icon and ToolIcon classes, ChangeAttributes.class, and Name.class.
All of these classes belong to the package builder and are stored, together with the Java code files in a directory called jLabView/builder.
There is ample javadoc documentation on each of the classes stored in a directory called Documentation, and also accessible from them web at:
The following is an abbreviated explanation of each of the classes that makes up the Builder interface.
Moveable.class: This is the most abstract of the classes in Builder. It might be a good idea to define it as an Abstract class. It takes care of all the basic needs of any moveable component of the system, such as: Initializing the objects attributes; defining the map that the object belongs to; setting and finding the location of the object within the map; moving the object and locking it in place; and taking care of all the mouse events associated with the object.
Node.class: This is a moveable object that represents a Module by it's Icon representation and can be used to inform a Map how to handle the information that it contains. It may also have a GUI representation that appears inside a Form and either accepts input from the user or presents results. May be turned into an Abstract Class. It takes care of such things as: keeping track of the components that make up a Module (Icon, Label or Name, GUI representation); defining the editing mode of the Module; and setting the particular attributes of the Module. It also has methods that take care of assigning wire connections to the Module and of propagating data through the Wires.
Icon.class: This is a moveable object that holds information about the Icon representation of a particular Node. It also contains information about the Node that it represents. It is an abstraction because it contains the methods necessary for producing and removing the icon, moving it in the map and locking it in place, as well as handling the different Mouse events associated with the icon, but it is not a specific implementation of a particular Icon. Each Node needs a specific Icon associated with it. That specific implementation of Icon holds the graphical representation of that particular Icon, and any special attributes that a particular Icon might have.
Wire.class: This class defines the objects that contain information about how the different nodes are connected to each other. This implementation of the Wire only allows for two nodes to be connected, the first one is the input and the second one is the output.
Note: This needs to be rethought. It may make more sense to define nodes in such a way that some nodes can only be input nodes and others only output nodes, in which case it wouldn't matter in what order they are connected, the data would only flow from input to output nodes. This is not the case now because we allow for a third type of node, Filter. A filter is a node that takes input and also produces output.
ButtonNode.class: This is a Node that contains a Button and implements the functionality of a complete Node (Icon plus GUI representation). It includes a method for displaying the graphical representation of the GUI component in both a running mode, and an Editing mode.
PullDownNode.class: This is a Node that contains a Choice component and implements the functionality of a complete Node (Icon plus GUI representation). It includes a method for displaying the graphical representation of the GUI component in both a running mode, and an Editing mode.
TextFieldNode.class: This is a Node that contains a TextField component and implements the functionality of a complete Node (Icon plus GUI representation). It includes a method for displaying the graphical representation of the GUI component in both a running mode, and an Editing mode.
Builder.class: Sets up the two editing windows of the system: Flow Control and Form. Also takes care of handling the events of the menubar on Flow Control.
Map.class: This is an object onto which either icons (in a flow control window) or GUI components (in a Form window) are drawn. It contains methods that allow for the addition of Wires onto the map, the addition of Nodes onto the map, and for locking their movement. It also includes methods that handle certain Mouse Events.
Note: This component needs to be extended so that it can save its contents to disk. The Map contains information about the whole interface, it contains all of its Nodes, which contain their own information, and it contains all of the Wires, which contain the information about how the Nodes interact with each other. Later in the documentation is an explanation of what needs to be saved, and why this implementation doesn't allow for it.
ToolBar.class: Sets up a Tool Bar for the Flow Control window. It contains a method for adding Icons of the different tools onto the bar and also handles the events on the Toolbar.
Note: The original idea was to make the icons on the Toolbar, draggable, so that the user could drag them directly onto either window when editing the interface. Unfortunately, that proved too complicated so the current implementation simply shows the Icons in the ToolBar as buttons that can be selected by pressing on them.
MyFrame.class: This is a "destroyable" frame.
StartApplet.class: This is an Applet that shows a button to start the program on any Java-enabled browser. The button, when pressed, runs Builder.
ChangeAttributes.class: This is our implementation of a Pop-Up menu that allows the programmer to change the attributes of each node. It produces a slightly different set of options for the different components. For example, a Pull Down Menu Node needs to be able to add options to the list. A Text Field, doesn't.
Note: May have to be rewritten in the next version of Builder.
Name.class: This is a moveable object that holds text. It is used for displaying the Label of both GUI components and icons.
Note: May be used to produce text on the form. If that is the case, it may include methods for making hyper-links.
Icons: They are extensions of Icon that implement the particular graphical representation of the Icon corresponding to each type of Node. The only Icons currently in use are an Input Icon and an Output Icon.
ToolIcons: They are extensions of ToolIcon that implement the particular graphical representation of the Tool Bar Component corresponding to each type of Node. The current implementation of these ToolIcons is a simple one with only a letter identifying each component.
Future Development: The current version of Builder cannot save either the Flow Control Map nor the Form interface to disk. This is a major flaw because it limits the usefulness of Builder as a practical tool. The easiest way to implement that capability is using one of the Data Streaming tools available with JDK1.1.1 (The current version of Builder was written using JDK1.0.2).
It seems logical to port Builder to the new version of Java, however doing so now may not be advisable. JDK1.1.1 needs a new Java Virtual Machine to be interpreted, therefore, any program written in it will not run on old Browsers, such as Netscape 3.0 or Internet explorer 4.0. Both Netscape and Microsoft have vowed to support the new Virtual Machine in their next versions of their browsers but that may not happen for another 6 months.
The other factor to take into account is that, in order to use new JDK1.1.1 features, it is necessary to make the whole program JDK1.1.1 compatible. This involves changing the names of some of the methods (which is not much of a problem, and can be done semi-automatically), and restructuring the whole event handling system.
JDK1.0.x used a simple event handling algorithm that has limitations. The new algorithm is much more flexible and makes more sense. Switching to the new algorithm will also solve some of the implementation problems that we had with the first version of Builder. The switch, however, will require some rethinking of the whole API.
One alternative is to create a more elaborate format for saving the Flow Control Map (which would automatically include all information pertaining to the Form that it represents) and implement it on the current version of Builder. This means that when Builder is ported to JDK1.1.1 (which seems inevitable) the saving methods will be simplified to use the new Data Streaming Classes.
For more information on converting the code into JDK1.1.1 please refer to the following website:
The other major component that Builder needs is a Node that will convert the data that it receives from other nodes into a Formatted Text file that it can send across the web to other computers for processing. This is necessary because of the original purpose of Builder which was to allow the user to build GUI's for the submission of batch jobs onto supercomputers. More information on this is available at our website:
With those two goals in mind, we suggest the following schedule of improvements:
Examples of using the Builder Editor. http://www.jwave.vt.edu/npib/builder1.0/instructions/index.html
Directory Structure for the Builder Editor. http://www.jwave.vt.edu/npib/builder1.0/
Class Hierarchy and Source Code for Builder. http://www.jwave.vt.edu/npib/builder1.0/builder/