Beyond Java - Bruce Tate [74]
What You Want
Current web application servers might be powerful, but they're not convenient or natural. So, what is convenient and natural? It shouldn't take too much effort to figure that out. What if your controllers looked like this:
if (logon.show() = = true) {
mainPage.show();
}
or this:
if (shoppingCart.verify()) checkout.show();
That's better. What you really want to do is encapsulate the presentation of one or more web screens in a method. Then, more sophisticated page flows would not be a problem. You could simply roll up more and more pages into higher-level components. For example, you could take this code:
checkoutAddress.showForm();
if(checkoutAddress.getSeparateBilling) checkoutBilling.showForm();
creditCardNumber.showForm();
and roll it up onto a method:
public static void showCheckoutWizard() {
checkoutAddress.showForm();
if(checkoutAddress.getSeparateBilling) checkoutBilling.showForm();
creditCardNumber.showForm();
}
so the usage becomes:
cart.showCheckoutWizard();
in its cleaner, refactored form. But you can't code that way, because your web server won't let you. Creators of most web application servers will sell their soul to keep things stateless and scalable.
Statelessness
Think of living without any short-term memory. Normal conversations in day-to-day life would be nearly impossible. Think of the logistics:
You'd have to write down every important phrase of every conversation as it occurred.
Then, when someone asked you a question, you'd have to look up the history of your conversation with that person before you could answer.
To optimize things, you'd have to decide how much information you should keep close by—say, in your briefcase—versus at home, in your filing cabinets.
When information got too old, you'd need to throw it out.
You'd have to maintain this whole system and revisit it when it didn't meet your needs.
That's the status quo for web developers. Your briefcase is the HTTP session, and your file cabinet at home is the relational database. It's an insane proposition, but we deal with the tedium because the Web is so important, and stateless solutions scale better. So, you willingly take a pretty large stride away from the ideal solution. Still, each time you struggle with the awkward little edge cases, you ask yourself if there's a better way, some kind of abstraction that fits the problem more neatly.
The Back Button
Saving state within simple conversations does not cover the whole problem. On the Web, conversations are not linear. Users can and do change their minds, pressing the Back button. Some assumptions that you've made as you continue to accumulate data may no longer apply.
Sometimes, you'll want to keep the user from going back, such as when she's made a purchase, or done something to force a committed change in a relational database. In these cases, you can simply punt and disable the Back button. Most often, you need to build special support for the Back button. You may even have to remove data from a database that a user would not have seen yet. Worse, many web designers simply don't solve the problem, and tell the user to expect unintuitive behavior. You've taken one more step back, away from the ideal. Once again, this awkward Back button forces you to deal with things on a case-by-case basis, and it just doesn't feel right.
Navigation
Web development in Java focuses an incredible amount of brain power around navigation and flow . You'd think controlling flow from the server side would be natural, but servers can't update clients—they can only respond to requests. This simple little truism forces servers to handle hundreds of little requests