Design

This page describes some of the design and organization of the Logic web application, its configuration files, and its data.

The Java classes are part of the edu.wlu.cs.logic base package.

LogicListener extends the ContextListener class.

A ContextListener sets up the ServletContext. The ServletContext is what all the servlets and JSPs in the application can “see”. It's where you keep a webapp's variables, like the ConnectionPool (the BasicDataSource) and the LogicData class that you'll use to communicate with the database.

For example, LogicListener sets up the pool of connections from the database. It reads the DB information from the context-parameters in the web.xml file. We have DB users and then we have the application's users, which we will create through the Adminstrator code.

AuthorizationFilter extends the Filter class. Basically, we implementing functionality to make that a user is supposed to be at a given servlet intAuthorizationFilter instead of putting it in each of our servlets. The AuthorizationFilter could change if we decide to organize data differently, but it was my best initial guess.

There should be an entry (<filter-mapping>) in the web.xml file where we put which servlets to filter. We'll need to figure out a regular expression to fill in there.

Look through this code to understand what you have to do in the login servlet code, such as creating a “user” attribute of class edu.wlu.cs.logic.User in the session object. Then “undo” that in the logout servlet, i.e., remove that attribute from the session.

I created a few classes in edu.wlu.cs.logic, one of which is User, but I did not fill in many methods.

The LogicData object is what holds the application's data and communicates with the DB. We want LogicData to make representations of the data in the database (like creating a User object) so we can use that “model” object rather than, say, a ResultSet object. If LogicData is the only class that communicates with the DB, then we only have one place to write/update SQL queries–rather than duplicating SQL queries in multiple servlets. Actually, we might want some SQL queries to be in, say, the User class rather than in LogicData, but still the SQL queries are not in the Servlets or in multiple places.

For example, you might want to do something like:

public class LogicData ...

  public boolean isAuthorizedUser(String username, String password) {
     // DB query ...
     return authorized;
  }

  public User getUser(String username, String password) {
     // assumes authorized user
     // use a connection from the pool of connections
     User user = new User(username, password, getConnection() );
     return user;
  }

}

public class User ...

  public User(String username, String password, Connection con ) {
     // Populate the user's data from the database
  }

  public User( String username, String password, String email, ...) {
     // another way to create a user object
  }
}

Both the LogicData class and the User class make queries on the database, but the Servlets have to go through the LogicData class because that is what is in the ServletContext and LogicData controls the DB connection pool.

You may need to cast a session's “user” into a Student or Professor object. The Student or Professor object can cache things like which question the student is on in the quiz or the professor's status for creating a quiz. Think of what's in the session as what is relevant for the logged in user and what you don't want to keep looking up in the DB.

The database's schema (organization of tables) is in the sql/ directory.

To connect to the database, you will need to change the DB user's name to your name in the appropriate context parameter in the web.xml file.

We are using the Orbital library to handle the complicated logic part of the application.

We need a class that translates between these symbols: