The Joist Framework
In order to navigate effectively through a set of applications, the joist framework provides some redirection mechanisms for common situations.
The joist framework supports modular servlet design. Servlet developers can choose to put all application processing into one big servlet, or they can break up the processing over a set of servlets. The sourceXchange site modularized according to the dictum of one servlet per page. Thus, for example, a servlet is responsible for displaying a particular form and for subsequently processing that form.
In the course of processing a request, a servlet can determine what page should be displayed next. If the next page is generated by another servlet, then the current servlet needs to redirect to the next servlet. This can be done by redirecting through the client (e.g., a browser) and is commonplace. On a high-traffic site, though, a full browser redirect can be expensive. For these servlet-to-servlet redirects, the joist framework can mimic a full redirect by redirecting internally, thus saving the network overhead.
Some pages need to be secured through SSL. Pages that display or prompt for passwords in particular must be encrypted. Credit card numbers, social security numbers, and other sensitive information should be encrypted as well. By using the https protocol (or "scheme"), the communication between client and server is secured with SSL.
The joist framework provides an easy way to stipulate that a page be secured; each servlet can specify the appropriate scheme in its properties file (as
servletScheme=). Switching back and forth between http and https requires a full client redirect. Joist handles the redirection automatically.
Has this ever happened to you? You work through a sequence of forms, then you get to the last screen, and there are no links to follow or buttons to push. You have to either use the "Back" button or retype the home page URL. I hate being stranded like that. I also feel that the flow through the site, and the applications particularly, should never require using the "Back" button. The user should always have a navigation path.
Thus the motivation for the "Cancel" button. We can quibble over the name, but the intent is to provide the user with an escape to a familiar screen should he ever head down the wrong path or into a dead end. Application servlets can register themselves as good targets for a cancel request. The framework maintains a stack of these cancel-to targets. The user can repeatedly cancel to unwind back to a good starting point for moving forward. If no cancel-to target is on the stack, cancel takes the user to his start page by default.
The cancel-to mechanism maintains the servlet name, action, and context for each cancel-to target, so the user can cancel back to, say, an RFP browse screen with its search criteria intact.
The mechanism eliminates duplicates. When the user revisits a servlet that is a cancel-to target, it pops the stack back to that servlet. Returning to the StartPage pops the stack entirely.