bikleDemo5.htm
05-06-2002 Bikle
-----------------

Bikle Java Demo #5

This is a simple demo of some classes which may be viewed as two
layers of software.

The first layer, what I call the "data layer", is a group of classes
which implement some simple memory structures.

The second layer, what I call the "interface layer", is a group of classes
which allow the user to access the data layer.

I implement this second layer in two different ways.  The first way
is a simple character interface.  The second way is a GUI.

Let's return our attention to the data layer.

Data Layer
----------
The classes which make up the data layer are listed below:

dataLayer/person-java.txt
This class contains three fields:
firstName, midName, lastName.
Also it contains methods for update and display of the above fields.

dataLayer/personAddress-java.txt
This class extends person by adding fields listed below:
addrStreet, addrCity, addrState, addrZip.
Also it contains methods for update and display of the above fields.

dataLayer/personAddressPhone-java.txt
This class extends personAddress by adding fields listed below:
phArea, phPrefix, phNumber.
Also it contains methods for update and display of the above fields.

dataLayer/personAddressPhoneWeb-java.txt
This class extends personAddressPhone by adding fields listed below:
eMail, Url.
Also it contains methods for update and display of the above fields.

Notice how personAddressPhoneWeb extends personAddressPhone which
extends personAddress which extends person.  This is an example of
serial inheritance.  Java does not support multiple inheritance
but for my needs, serial inheritance works fine.

dataLayer/objArray-java.txt
This class allows me to collect instances of personAddressPhoneWeb objects
in an array.
Also, this class allows me to act on the array in a variety of ways:
insert, find, delete, and display objects.  


Character Interface Layer
---------------------------
The classes which make up the character interface layer are listed below:

charUI/aMain-java.txt
charUI/charUI-java.txt
charUI/fromKeyBoard-java.txt

A jar file which contains both the character interface layer
and the data layer is linked below:

charUI/charUI.jar

A UNIX shell command to run the "aMain" class in the above jar file
is displayed below:

/bin/java -cp charUI.jar aMain

How do I describe the charUI class?

The charUI class is a simple character interface which provides user access
to these constructors and methods:

new personAddressPhoneWeb()
objArray.addObj()
objArray.findObj()
objArray.delObj()
objArray.dispObjArray()

Notice that I create an objArray object inside the charUI class.  This
allows the charUI object to gain access to the objArray object.  I
could have created the objArray object inside the aMain class (outside
of the charUI object ).  If at that point the charUI object wanted to
access the objArray object, I would have needed to pass the objArray
object into the charUI constructor.

I demonstrate the passing of the objArray object to a constructor in
some of the GUI demos below.


GUI Layer
-----------
The classes which make up the GUI Layer are listed below:

b5GUI.java
This class displays the initial interface.  It leads the user into these dialogs:
-Add a record to the objArray instance
-Look for a record in the objArray instance
-Delete a record from the objArray instance
-Display all the records in the objArray instance

The class displays a button corresponding to each of the above dialogs.

I have a button handler class for each of the above buttons:

addButtonHandler.java
lookButtonHandler.java
delButtonHandler.java
dispButtonHandler.java

In addition, I have a class which corresponds to each of the above dialogs:

addGUI.java
lookGUI.java
delGUI.java
dispGUI.java

The first three classes each contain a button, so I provide button
handlers for the three different buttons:

addGUIhandler.java
lookGUIhandler.java
delGUIhandler.java

The order in which I wrote these classes is listed below:

addGUI.java
dispGUI.java
lookGUI.java
delGUI.java
b5GUI.java

addGUIhandler.java
lookGUIhandler.java
delGUIhandler.java
addButtonHandler.java
lookButtonHandler.java
delButtonHandler.java
dispButtonHandler.java

When I put this thing together I wrote the classes in different stages.

Initially, I wrote the GUI classes without any button handlers in them.
Also I wrote them so they made no reference to the objArray class.

Once I got them written and debugged, I made copies of them.  
Copies of the "bare-bones" GUI classes are displayed below:

gui1/aMain-java.txt
gui1/b5GUI-java.txt
gui1/addGUI-java.txt
gui1/dispGUI-java.txt
gui1/lookGUI-java.txt
gui1/delGUI-java.txt
gui1/WindowControlDispose-java.txt
gui1/WindowControlExit-java.txt

A corresponding jar file is linked below:

gui1/gui1.jar

A UNIX shell command to run the "aMain" class in the above jar file
is displayed below:

/bin/java -cp gui1.jar aMain


Next I added references to the objArray class:

gui2/aMain-java.txt
gui2/b5GUI-java.txt
gui2/addGUI-java.txt
gui2/dispGUI-java.txt
gui2/lookGUI-java.txt
gui2/delGUI-java.txt
gui2/WindowControlDispose-java.txt
gui2/WindowControlExit-java.txt



Next, I added the button handlers and then made more copies.
Those copies are displayed below:

gui3/aMain-java.txt
gui3/b5GUI-java.txt
gui3/addGUI-java.txt
gui3/dispGUI-java.txt
gui3/lookGUI-java.txt
gui3/delGUI-java.txt

Notice that I rewrote gui3/dispGUI.java to make use of a GUI "helper" class named 
gui3/GUIoutJTA-java.txt

Here are the handlers:
gui3/addGUIhandler-java.txt
gui3/lookGUIhandler-java.txt
gui3/delGUIhandler-java.txt
gui3/addButtonHandler-java.txt
gui3/lookButtonHandler-java.txt
gui3/delButtonHandler-java.txt
gui3/dispButtonHandler-java.txt

Some GUI "helper" classes:
gui3/GUIoutJTA-java.txt
gui3/GUIOut-java.txt

One bit of weirdness associated with some of these classes is a dependency issue.
If you have classA which depends on classB which depends on classA then you
will not be able to compile either of the two classes.  The obvious work-around is
to comment out all references to classB in classA.  This will allow you to compile
classA.  Then, you would be able to compile classB.  At that point, you should put
the classB reference back in classA and then compile classA.

The classes which have this dependency issue are listed below:

addGUI.java depends on addGUIhandler.java which depends on addGUI.java
delGUI.java depends on delGUIhandler.java which depends on delGUI.java
lookGUI.java depends on lookGUIhandler.java which depends on lookGUI.java

Next, I should point out that the classes listed below make use of
the keyword: "implements":
gui3/addGUIhandler-java.txt
gui3/lookGUIhandler-java.txt
gui3/delGUIhandler-java.txt
gui3/addButtonHandler-java.txt
gui3/lookButtonHandler-java.txt
gui3/delButtonHandler-java.txt
gui3/dispButtonHandler-java.txt

Some jargon I use to describe what's going on here is this:
"The above 7 classes are implementing the ActionListener interface."

The main idea the reader should walk away with is this:  "A class which
implements an interface must obey some rules."  

This is a good thing because it allows developers to write reusable
code more easily.

Notice how easy it was for me to make use of the ActionListener
interface to tie software actions to the act of a user pressing a
button.  I did not need to worry about the details of a loop which was
constantly checking the location of a mouse or the state of a mouse
button.  The Sun.com software brains took care of that for me.
Although the Sun.com developers are brilliant, they have limits.  They
do ask me to follow some rules.

All I had to do was follow this simple recipe:

-Create a class (I call it a button handler class) in a specfic way:
  -Make use of the "implements ActionListener" keywords
  -Declare a method named actionPerformed() in the class
  -put variable of type "ActionEvent" in the actionPerformed() parameter list
  -Add code to actionPerformed() which I want the button to trigger.
-Register the button handler class with the button 
  -Build a GUI object to hold the button
  -Create the button object in the GUI object
  -Create a button handler object in the GUI object
  -Feed the button handler object to button.addActionListener()
   -demo: JButtonAdd.addActionListener(XaddButtonHandler); 

Once you get the hang of it and do it a few times, it's easier than
removing a motor from a lawn mower and then using it to power a
skateboard.

If you want a more polished discussion about interfaces, see
the URL listed below:

http://java.sun.com/docs/books/tutorial/java/interpack/usinginterface.html


A corresponding jar file is linked below:

gui1/gui3.jar

A UNIX shell command to run the "aMain" class in the above jar file
is displayed below:

/bin/java -cp gui3.jar aMain


Now that I've demonstrated how to create button handlers, I'll show the reader
how to pretty up some of the Swing components.

Keep in mind, however, that Swing is a huge topic.  The purpose of
this tutorial is not to teach Swing.  Rather this tutorial uses a few
simple Swing classes to move the reader towards an object orient mode
of thinking.  This type of thinking is best taught using actual
objects which the reader can see and move around with a mouse.

On the other hand, the Swing objects displayed up to this point in the
tutorial are very crude; it doesn't hurt to show the reader how to
make them a little more friendly.


First, I'll focus on this class:
gui4/GUIoutJTA-java.txt

This was easy to enhance; I just added scroll bars.  The Swing
class to help me with this is JScrollPane.

It's easy to use; just create the JScrollPane.

Then, pass the JTextArea to the JScrollPane rather than to the
JPanel object.

Once the JTextArea is added to the JScrollPane, I add the
JScrollPane to the JPanel object.

Next, I'll focus on this class:
gui4/addGUI-java.txt

The enhancements made to this class were a bit more involved.
The first enhancement was the creation of a GridLayout object
which was then passed to the aJPanel.setLayout() method:

    aJPanel.setLayout(new GridLayout(14,2));  

Next, I added a series of JLabel and JTextField objects to aJPanel.
The GridLayout object works some magic at this point to put the
objects into a grid of 14 rows with 2 columns.  The main idea here is
that I need to be careful about the order in which I add the objects
so the JLabel objects visually match the JTextField objects.
Finally, the last enhancement I made was the removal of 
Strings which automatically populated the JTextField objects.
Originally, I put the Strings in there as a debugging aid.
The Strings had contained a copy of the name of the corresponding
JTextField; they acted a bit like a poor-man's label.

Next, I'll focus on these classes:
gui4/lookGUI-java.txt
gui4/delGUI-java.txt

The enhancements made to these classes were easy.  I created two
JPanel objects instead of just one.  Next, I put a border around each
JPanel object to help me visualize their location.  Then, I used
keyword: "North" to put the search string JTextField at the top of the
JFrame.  I used keyword: "South" to put the JButton object at the
bottom of the JFrame.  Also, I used the "North" JPanel to keep the
JTextField and its corresponding JLabel near each other.

I display below a list of all the classes which I used to test these
enhancements:

gui4/GUIOut-java.txt
gui4/GUIoutJTA-java.txt
gui4/WindowControlDispose-java.txt
gui4/WindowControlExit-java.txt
gui4/aMain-java.txt
gui4/addButtonHandler-java.txt
gui4/addGUI-java.txt
gui4/addGUIhandler-java.txt
gui4/b5GUI-java.txt
gui4/delButtonHandler-java.txt
gui4/delGUI-java.txt
gui4/delGUIhandler-java.txt
gui4/dispButtonHandler-java.txt
gui4/dispGUI-java.txt
gui4/lookButtonHandler-java.txt
gui4/lookGUI-java.txt
gui4/lookGUIhandler-java.txt
gui4/objArray-java.txt
gui4/person-java.txt
gui4/personAddress-java.txt
gui4/personAddressPhone-java.txt
gui4/personAddressPhoneWeb-java.txt

A corresponding .jar file is linked below:
gui4/aMain.jar

On Solaris, run the above .jar with the command line listed below:

/bin/java -cp aMain.jar aMain