What Do We Want?
All too often, we start by asking what a tool can do for us, when we should be asking what we want our app to do. We want our apps to display information to users, accept input, execute transactions, and display more information. Figure 1 is a transition graph in classic MVC format illustrating this point. The application starts by displaying the LoginPage, which transitions to either the VerifyLoginController (passing an ID and password) or to a NewVoterController (passing nothing). If the login is valid, the StatusPage is displayed, showing details about the Voter and elections voted in. If not, it's back to the LoginPage with an error message.
It appears that most infrastructures and most web designers think in terms of page-to-page transitions. ("The LoginPage can transition to either the VerifyLoginPage or the NewVoterPage.") This is unfortunate because page-to-page transition graphs leave out essential information and result in horrendous hacks ("forwarded" pages, anyone?) to get around perceived problems.
Languages at Different Levels
Java is a lousy language for describing page layout, and HTML is no good at logic. So we do want to use several different languages to define our applications. Can we do it and still avoid ITC? There are four basic levels I see for web apps, each of which is best done with its own language:
- Data Definition can be done by choosing a name for the object you want and listing its components. This Person[String name, int age, String address] is minimally sufficient. You can generate stubs in Java, a presentation description in HTML, and build a persistence definition from it. And that's what we want. (Dealing with a back-end database can be done entirely automatically. You only write calls like dataObject.persist(). No SQL. No ITC.)
- A Transition Graph lets you say which controller calls which set of pages, and what data those pages display. It also says what information those pages will have to solicit from users when transitioning to the next controller. You can build stubs for both the page layout and controllers from it.
- Page Layout is best done with a WYSIWYG editor. You can hand the editor the page stub you just created (which will have basic HTML to display the data) and do all the positioning and pretty details there.
- Logic is built up from the controller stubs, using whatever programming language you find suitable. (I like Java.) Because you're generating all the stubs from the transition graph, you can generate specific Request objects for the controllers that do all of the data verification and data object creation for you, letting you write things like request.getUID() instead of request.getParameter("UID"). No ITC!
In this fashion, there is a single source for all the name strings and the generator, plus the compiler guarantees that no naming mistakes are made. The tricky part of dealing with multilevel designs like this is ensuring that changes in one language (say, the transition graph) are appropriately reflected in the generated code; and you must prevent programmers from changing the generated portions of the code to conflict with the graph. But this is an issue for tool designers, not application programmers.
What about those 11 languages? Don't they serve a necessary purpose? Yes. You just don't want application programmers to have to deal with them directly. You want them to be treated the same way we treat assembly code—as something that's generated for us. It's great to have web pages do local field validation. It's just that the validation code should be generated from the data description for us. The same goes for just about everything else in that list.
