README for Final Project, cscie247,  Russell Lowke  March 5th 2004.


Design and Implementation choices for DistressServer and DistressClient.


Note: DistressServer and DistressGUIClient both accept a hostName and portNumber as parameters.  If these are not specified then a default hostName of "localhost" and a portNumber of 1099 is used.  My .bat files do not specify hostName nor portNumber, thus defaults are used.


SERVER SIDE

	All exceptions that can't be dealt with specifically bubble to the top and are printed as errors in main() of DistressServer.

	Distress uses a --SINGLETON-- pattern instantiated in DistressImpl and passed to DistressServer to be registered in the registry [DistressServer.java lines 297-307]. The distress.server package objects communicate through the single DistressImpl class, and, as such, is an example of a --FACADE-- pattern.

	In the distress.server package DistressImpl, ConsumerImpl, and RealtorImpl classes all implement add(), remove(), and list() methods that take advantage of ubiquitous Object parameters so to reuse the same methods, in particular the --ITERATOR-- pattern is used to iterate through and access the various lists.  There are many instances of ITERATOR, too numerous for all to be listed here.

	To cater for Remote Method Invocation (RMI) there are implementation classes and interfaces to the Distress server objects, implementations have a suffix of "Impl", while the interfaces are called the base name of the object.  The Distress domain as eight implementation classes, these being:
    UserImpl.java  SingleFamilyImpl.java  RealtorImpl.java  PropertyProfileImpl.java  PropertyImpl.java    
    DistressImpl.java  ConsumerImpl.java   CondominiumImpl.java

	Common elements such as shared interfaces, defined exceptions, enumeration types, SearchCriteria and SearchItem are all stored in the package cscie247.distress.  Enumerations, SearchCriteria and SearchItem are serializable as they are passed remotely.

Implementation of RMI in Distress, with its interfaces and Impl classes is an example of the --REMOTE PROXY-- design pattern.


CLIENT SIDE

	All exceptions that can't be dealt with specifically bubble to the top and are printed as errors in main() of DistressGUIClient.  Many exceptions can be dealt with specifically, the most common of these being due to input errors by the user when bad syntax is supplied.  Such input errors are handled by the DistressScreen displaying a generic error alert or info dialog box informing the user of the issue, thereby creating a robust environment.  Code to handle these standard alert and error dialogs can be found in the abstract class DistressScreen on lines 117-139.

	The --TEMPLATE-- pattern is used by all the distress screens, as they all extend the abstract class DistressScreen.   DistressScreen declares three compulsory template methods called setUpInfoPanel(), setUpWorkingPanel(), setUpCommandPanel(). The definitions for these template methods [abstract] can be found in DistressScreen.java lines 112-114.  Each of these methods return a JPanel which are uniformly and consistently added to each screen's content pane in the constructor for the abstract DistressScreen.  This adheres each screen to a consistent template, hence --TEMPLATE-- pattern.

	The --OBSERVER-- pattern is inherent in the use of the Swing classes.  The various Swing Listeners are all observing various controls waiting for a chance to respond.  Specifically; I have ActionListeners attached to JButtons in all the setUpCommandPanel() templates; a WindowListener is attached to each and every window; ActionListeners are attached to the JComboBoxs in the setUpWorkingPanel() of both the ConsumerScreen and the SingleFamilyEditScreen, to deal with popup menu states; there are KeyListeners attached the JTextFields in SingleFamilyEditScreen, MainDistressScreen, and ConsumerScreen to toggle the various button states in the command panel.  These Listeners are all observing their respective controls using small anonymous classes that know how to respond.  They are all good examples of the --Observer-- pattern, resulting in event driven programming so common to GUI environments.

	I have used the --MEDIATOR-- pattern to contain and translate all the various --OBSERVERS--.  It is used in conjunction with the --TEMPLATE-- pattern as each setUpPanel method [setUpInfoPanel(), setUpWorkingPanel(), setUpCommandPanel()] is a --MEDIATOR-- containing a host of OBSERVERs attached to various Swing J components.  By use of anonymous classes the --OBSERVER-- Listeners' are consolidated within their respective --MEDIATOR-- panels.


Client Side implementation:

	DistressGUIClient is the entry point which looks up Distress from the registry, then passes the Distress to the first screen MainDistressScreen, which stores it as a static member variable in the abstract parent class using the static call MainDistressScreen.setDistress(mDistress).
	Important to note is that there is no GUI window manager class, instead each screen class has a static method called openWindow() which stores information for that window in a static member variable called thisWindow.  So, when DistressGUIClient needs to open the MainDistressScreen it simply calls the static method MainDistressScreen.openWindow().  To close its window each screen also has a static method closeWindow(), which uses thisWindow.setVisible(false) and then sets thisWindow = null, neatly disposing of said screen.
	As mentioned, each screen extends from DistressScreen, whose constructor immediately adds the windows three template panels to the screen's ContentPane. The screen/window is also positioned in the center of the computer monitor and made visible.  The three panels, being mediators, contain all the components that make up the screen and its functionality.  The observers and components take over and the screen waits to respond to the user in an event driven fashion, the specifics of which may be found in the "PURPOSE" section of the remarks as the beginning of each screens .java file.




Russell Lowke
