A Unit of Web-Base User Interaction
Unfortunately, the Internet (actually, just HTTP) was designed for only the simplest user interaction. But because HTTP is the universal protocol — everyone happily uses a web browser — developers are forced to find ways to make web pages interactive in order to make web-based applications.
A unit of user interaction is one iteration of the cycle that users go through. Assume the user is currently looking at the home page of an Internet Banking application and they want to log in.
The first unit of interaction:
- The user enters their username and password, then clicks the “Login” button which submits the form.
- The HTML is wired so that submitting that information takes them to the “login” page.
- The web server receives a request for the “login” URL, with the username and password stored as additional information in the request.
- The web server passes that request to the “login” controller. (see UnderstandingHowRequestsAreRouted if you want more information about what’s going on “under the hood”)
- The login controller checks the user’s credentials and remembers the user’s ID in the session for successive requests.
- The login controller redirects to the “accounts” URL.
The second unit of “interaction” (not genuine interaction because the user didn’t select anything, but it’s a new cycle):
- The “accounts” URL gets routed to the accounts controller.
- The accounts controller asks the session “do I know this user?” and based on the sessions information, retrieves that user’s profile from the database (through the user model).
- The controller massages that information to be relevant for the view, and asks the web server to render the “accounts” page.
From here, the user can click on different accounts or other operations (transfer funds, pay bills, etc.). Whatever the user decides to do, new controllers will be invoked to process the “request”, the session will be consulted, the model will be accessed, and new views will be rendered.