Front-End

Introduction

The frontend for the advisement system is responsible for retrieving input from and displaying output to the user, and the formatting of data to be fed into the Processor subsystem.  Attention has been paid in making this portion of the system as independent as possible from the specifics of the calculations done is the processor, in hopes of making the two systems as encapsulated as possible.  In fact, the two subsystems interact only through one method call, and therefore changes to either should be relatively transparent to the other.

Changes made to the web.xml file

The following lines must be added to the web context web.xml file (somewhere in between the <web-app> and </web-app> tags) in order for the Front-End to function properly:

<listener>
    <listener-class>LifeCycleListener</listener-class>
</listener>

These lines register the class LifeCycleListener as interested in the servlet's life cycle events.  This class implements the HttpSessionListener and the ServletContextListener, effectively telling the java web server to send it events indicating when the context is created and destroyed, as well as when a user connects and disconnects.

HTMLUtils

This class is the major building block for which all the servlets in the Front-End are created.  It contains several static methods that print out HTML form constructs, tables, and standard headers and footers for each page.  The usage for the methods should be relatively straightfoward based on the individual parameters, however the printTable and similar methods need some extra explaination.

Each table printing method in this class takes a collection of String objects.  Each String represents a row in the table, where each cell is delimitted by a pipe symbol ( | ).  Each row may have any number of cells, and the number of cells per row may vary.  Additionally, there may be any number of tables in a collection.  Each table in the collection (including the first) must have a special row to indicate that a new table is being defined, where the special row is also delimmited by pipe symbols.  The format of the special rows are as follows:

*|Title|y/n

The star field is what indicates to the table printer that a new table is being started, and that the current String defines a special row.  The middle field specifies a title to place over the HTML table when it is rendered.  The final field is either a y character or a n character indicating if the next row after the special row is a header.  A header row is like any other row, except any text it contains is bolded.

An example of Strings that could be passed in as a collection to one of these methods is as follows:

*|Phone List|y
Name|Phone Number
Brian|555-5555
Bill|999-9999

This will create a table similar looking to this:

Phone List

Name
 Phone Number
Brian
 555-5555
Bill
 999-9999


SSL and Certificates

In the initial creation of the advisement system, the java SSL standard library was utilized unchanged and worked perfectly.  Unfortunately, in the middle of the project, the school upgraded the server hosting the Banner database system and added a newly created SSL certificate.  The classes in javax.net.ssl did not recognize the new certificate as valid, and refused to proceed lacking proper authentication (it through an exception).  To work around this the classes DummySSLSocketFactory and DummyTrustManager were created in order to allow the certificate problem to be bypassed.  These classes act as a thin wrapper over the standard SSL classes provided by java, and simply allow untrusted certificates to be accepted.  When instaniated, the class DummySSLSocketFactory can be set as the default SSLSocketFactory via the HttpsURLConnection.setDefaultSSLSocketFactory() method, and therefore allow the Banner certificate to be accepted.  In SAS, the DummySSLSocketFactory is setup from within the LifeCycleListener class to allow connections to Banner to occur without invalid certificate exceptions to be thrown.  If these certificate problems are resolved at a future date, this call may be removed to go back to using the normal SSLSocketFactory and TrustManager classes.

TranscriptParser and TranscriptReciever

These two classes provide a means to access, download, and parse a student's transcript given their username and password.  TranscriptReciever is what does the connecting, and TranscriptParser parses the HTML from the TranscriptReciever into usable data for the Processor.  Since HTML tags only store display information, there is no 100% clean way to get the transcript information.  Thus, the TranscriptParser class relies heavily on finding specific pieces of text within transcripts, synching on it, and then parsing the table cells that follow.  Any changes made to Banner are likely to impact these two classes, and to keep them working modifications will undoubtedly be necessary.

Test Programs

To help make modifying the TranscriptParser and TranscriptReciever classes easier, two test programs exist in with the rest of the system, Test_GetAndParseTranscript and Test_PrintTranscriptHTML.  The first of these two classes will download and parse a student's transcript, then dump the information parsed onto the screen.  The second will simply download the HTML, and dump it to the screen.

Interface to Processor

As mentioned prior in this document, the Front-End and the Processor only interact through one method.  The calling of this method is made in the Output servlet, and looks something like:

map.put("courses", courseList);
map.put("major", major);
map.put("secondmajor", secondMajor);
map.put("minor", minor);
map.put("coreneeded", coreNeeded);
map.put("totalcredits", transReq.getTotalCreditCount());
map.put("transfercredits", transReq.getTransferCreditCount());

String errorStr;
if((errorStr=InputChecker.isInputMapOk(map)) != null)
{
     HTMLUtils.printRedirectPage(out, errorStr, "Input");
     return;
 }

Processor processor = new Processor(map);
ArrayList arrList = processor.go();

The variable map is any object implementing the abstract Map interface, and is used to store the variables parsed from the student input and the transcripts.  The call to InputChecker.isInputMapOk() validates that the inputs the user has provided are valid before being passed into the Processor. Finally, the map is passed into the Processor's constructor, and then the go method is invoked, which starts the calculation process.  The return value is an ArrayList object, containing a number of String objects to display on the screen.  These Strings are expected to be in the form used in the HTMLUtils printTable methods so that the output can be displayed on the screen without knowledge of the specifics of its layout and contents (this format is described above in the HTMLUtils section).

Here are the specifics of what is expected of each variable passed into the Processor through the map: