g number of Java development systems incorporate robust bean support; such is the case with PFJ.
PFJ's parts are the visual and nonvisual objects that populate a PFJ application (or applet). You create a Java application by the now-familiar activity of dragging and dropping parts into a Java application's frame.
Once a part (which is really a bean) is in place, you modify its characteristics through property sheets -- dialog boxes that are packaged with the part (rather than being part of the IDE) and that provide access to a part's characteristics (such as its color or font).
Ordinarily, you access a part's property sheet by double-clicking on the part. PFJ improves on the bare-bones property sheet dialog box by adding a drop-down listbox (within each property sheet dialog box) that provides quick access to other parts in the application. This allows you to rapidly move from one part to another in the
application; you don't have to close the dialog box and then click on the next part to open the new property sheet dialog box.
Programming with Wires
I've seen many implementations of visual programming by means of wiring together on-screen objects, such as buttons or scroll bars. IBM's Visual Age for Java was my most recent encounter with an IDE that used this paradigm. (In fact, Visual Age also used parts as the fundamental visual-programming component.) PFJ demonstrates what I think is -- so far, at least -- the best visual-programming environment of this sort for Java.
For example, suppose you want to establish a relationship between one part that is an event source and another that is the recipient of (and will respond to) that event. If you right-click on the source part and drag to the destination part, PFJ opens a
dialog box
showing the events provided by the source and the responding methods offered by the destination. Select the event and receiving method,
and PFJ will deposit the correct source code in your application's .java files.
Simultaneously, PFJ draws a connecting line between source and destination parts, and displays floating text boxes that carry the prototypes of the source event and recipient method. PFJ inserts placeholders in the latter's argument list; each placeholder consists of the corresponding object's data type and a solid-color diamond. (The diamond is replaced with the actual argument once you complete the definition of the method call.) If a link is incomplete -- perhaps you haven't specified arguments needed in the receiving method -- it glows red. (If you're building a complex user interface, this helps you quickly spot portions of the application that are unfinished.)
PFJ handles complex event/target relationships easily. That is, although an event implies a source part, which generates an event, and a target part, which responds to that event, the relationship can be more elaborate than that. For example, the target mi
ght call a third part to supply an argument for the target method. Just as you can wire the source and target together, you can connect a part to an argument in the target's method. That's where the placeholders come into play. They act as anchors for the connection between part and argument.
So, suppose that in response to a button-click event, a listbox copies the contents of a text box into the list. You can create a link between the text box and the method called in the listbox by right-clicking on and dragging between the placeholder I mentioned earlier and the text box. The IDE will open a dialog box showing available "getter" methods in the text-box part for retrieving the text box's current string. When you select the proper getter method, PFJ does the coding for you.
Compliant with JDK 1.1.2
PFJ supports the JDK 1.1.2's delegation event model. This makes it among the first IDEs that I've seen with explicit support for the delegation event model, though more JDK 1.1.2-compliant ID
Es will probably be available by the time you read this. Now, instead of PFJ generating an explicit source code event loop for managing event/target links, it simply generates a method call that registers the destination part as an "action listener" to the source part.
The source code that PFJ generates is deceptively simple. This simplicity is due partially to the delegation event model (and the consequent lack of an event loop). It's also due partially to the implementation of parts as beans. This latter fact means that a part's behavior is encapsulated in the bean and never appears in the source code that PFJ automatically generates. Nevertheless, because so much behavior is abstracted into the parts, the mechanics of the generated code are quite easy to comprehend.
Good Parts
Beyond the IDE, PFJ also includes support for Common Object Request Broker Architecture (CORBA) and remote method invocation (RMI). On the CORBA side, PFJ arrives with a trial version of Iona's OrbixWeb (which su
pports IIOP). On the RMI side, PFJ's RMI wizard guides you through setting up both sides of a remote method call.
PFJ's ClassMaster browser is its most obvious inheritance from the Smalltalk world. A classic three-pane browser, ClassMaster provides a unified view of a given class. That is, it will show you not only methods defined within the class, it will also show you any methods that the class inherits from its superclass in a single view. In that way, you can quickly get a picture of a class's total functionality.
Finally, PFJ's debugger, which is multithreaded and as good as any that I have seen, is written entirely in Java. That makes it portable to any platform that supports Java.
Although I haven't tried it yet, this portability should allow you to tackle those situations where an application runs well on one platform but fails on another (yes, this sometimes happens with Java applets). You can move the debugger wherever you need it.
Parts for Java is available from ObjectShare
for a price of $149. You can purchase it at the following Web site:
http://www.objectshare.com
.
Rebuilt Parts
