The Joist Framework
Since we're using WebMacro, all joist servlets indirectly subclass WMServlet instead of HttpServlet directly. Common functionality has been factored out to two abstract classes, UnsecureServlet and SecureServlet. All joist application servlets subclass one or the other of these.
| +---- e.g., MilestoneAnnounce
+---- e.g., UserRegistration
The bulk of the code is in UnsecureServlet. It is primarily responsible for processing the request according to the specific application servlet, then invoking the WebMacro template engine with the proper template and associated data.
The servlet request may specify an action, either as the result of the user pushing a button on a form, or via the URL query string. Some common actions, such as the redirect for Cancel, are processed directly by UnsecureServlet.
Servlet redirection is handled by UnsecureServlet. It implements a set of convenience methods for initiating a redirect. It also intercepts the redirect and, when possible, handles it internally, thus avoiding sending the redirect back to the browser.
When transitioning between SSL-secured servlets and those that are not SSL-secured, redirects must go back to the browser, though. The fact that a servlet is SSL-secured or not is configured via
servletScheme=[https|http]in its properties file. The default is http. The redirect for http-to-https and https-to-http transitions is triggered automatically.
UnsecureServlet ensures that, barring any over-ride, the default template for the application servlet is offered up for rendering the response html. The
servletTemplate property in the servlet's properties file specifies the servlet's default template. The application servlet has the perogative, in the course of its processing, to over-ride the default, though this is not the usual case.
The UnsecureServlet also acquires a database connection for the duration of the request. The connection is saved in the WebContext so that any object involved in the servlet processing can use it (and knows where to find it by convention). When the request is fully processed, the connection is returned to the connection pool.
UnsecureServlet takes care of some basic housekeeping, such as ensuring that standard information is present in the WebContext. It also reads the servlet's default template from
servletTemplate in the servlet's properties file. The application servlet has the perogative to over-ride the default, though this is not the usual case.
The SecureServlet extends UnsecureServlet by enforcing that the user has logged in first. If not, the user is rerouted to the Login screen.
The rerouting through the Login screen preserves the original request such that the user is routed there following successful Login. So if the user tries to update a proposal, but has not yet logged in, he will be asked to Login first. If the login is successful, he with be routed to the proposal update screen automatically. By default, the Login page leads to the user's StartPage (personal home page)
The SecureServlet also enforces that the user has at least the base level permission to be accessing the specific application servlet at all. Each servlet's base permission is specified in its properties file (as