I have great sympathy for JSP programmers. It follows that, from time to time, I feel sorry for myself. We’re supposed to love Java and be lukewarm to HTML, but we can never use the first inside the second. (Let’s leave aside that writing Java inside HTML is the original purpose of JSP.)

I suspect that the origin of this embargo is the blatant ugliness of curly brackets mixed with HTML. (Even EE programmers have that much aesthetic sense.) Instead you’re encouraged to mask logic using a set of custom tags that are, supposedly, not a joke propagated by an underground cartel of existential programmers:

    <c:choose>
        <c:when test="${person.isHappy}">I'm happy!</c:when>
        <c:otherwise>I'm not so sure.</c:otherwise>
    </c:choose>

That was an if / else, if you couldn’t tell. XML control tags are the accepted back door to coding a page that thinks. But what if you need to access something besides a simple property: is person A happy with person B? Well no biggie, you anticipate the need in the servlet (or “action” or “controller”) and set a response parameter.

Oh, did I mention this is inside a loop? In that case you must construct a rather complicated data structure in the servlet, which you’ll loop through on the page using <c:for>. That will work, if you try hard enough.

Later you may learn that you need a similar display on another page. You can either copy & paste about a hundred lines, or do the right thing: write a custom tag. So you add a descriptor to your tag library, and proceed to code the tag class. Unfortunately the loops and conditionals in the page must be translated from XML to Java, and the complicated data structure from the servlet is mostly useless. You pass in parameters through attributes of the tag, and then splice together HTML in the Java class without any help from anything.

So there went one week of a programmer’s life. Next time he’ll just tell the man, “sorry, we can’t do that.” It’s no wonder that most Java-driven sites are lifeless. Having “logic” is what a good interface is all about, but the hurdles for doing it in a Model 2 Web app are high, and therefore expensive. You want that control to reflect the object’s status? It’ll cost ya $500.

Meanwhile in scripting land, they’re generally blessed with a syntax that looks much less out-of-place in HTML—and they aren’t afraid to use it. Creative interfaces, instead of being dismissed as low-priority business objectives, are just done.

The upshot is that there’s a better way to extract logic from the template, one that yields dividends beyond a jarchitect’s approving nod. Since Wicket dives head-first into HTML tag construction with its component hierarchy, it enables painless (and mostly unseen) object oriented markup processing of the entire page. A wicket:id connects the markup to the code, and the logic is in Java. Not by convention: it just is.

Although I wish Wicket had happened sooner, I’m not sure it would have been as effective in a pre-CSS Web. Let’s see, how would I elegantly append this <BR> ? But those are concerns of the past. These days HTML is a lightweight, hierarchical structure just begging to be manipulated by program code.

So don’t hold back. Get medieval on your markup.