Russell Beattie

I haven't actually done a lot of programming with Velocity yet, so I don't really know it's downsides, but I'm DESPERATE to get out of the Tag Library Hell I'm in now. Hey, tag libraries were a really cool idea at first. They look so good in theory: Replace all that ugly code on the page with clean tags which put the programming back in the Java classes where they belong. But the whole idea has been twisted to the point of being useless. Once someone implemented switches and iterations using tags (which was .05 seconds after they were thought up), it was all downhill from there. We're now doing programming on the web pages using XML, which is NOT a programming language. And not only that, but Sun has STANDARDIZED this wacky form of development. Someone is asleep at the switch at Sun.

My biggest fear is that more and more people are using tags and projects are requiring them, so they're going to be with us for a long time. I wish it weren't true, but it is. Tags are hell to work with. Debugging tag libraries is a nightmare. Finding logic bugs on the page is impossible. I need to use a special editor which will match up start and end tags (I use IntelliJ), because if I don't it's incredibly easy to get lost in tags within tags, within tags... Maybe I'm old-school. But if I can't be productive with a normal text editor, something is wrong.

Look at this example, it's from the recent O'Reilly articles about the JSTL:

<c:choose>
<c:when test="${param.first > 0}">
<a href="foreach.jsp?first=<c:out value="${param.first - noOfRows}"/>">
Previous Page</a>
</c:when>
<c:otherwise>
Previous Page
</c:otherwise>
</c:choose>
<c:choose>
<c:when test="${param.first + noOfRows < forecasts.rowsCount}"> <a href="foreach.jsp?first=<c:out value="${param.first + noOfRows}"/>">
Next Page</a>
</c:when>
<c:otherwise>
Next Page
</c:otherwise>
</c:choose>


Can ANYONE tell me what the HELL that code is doing? That's just a simple example and it's unmaintainable as hell. And it's using the new JSTL Expression Language to boot, which is supposed to help make life easier. It's just adding more complexity and unmaintainablity.

Another code snippet, this time from from WebWork:

<webwork:iterator value="weeks">
<TR>
<TH><webwork:property value="@week/next"/></TH>
<webwork:iterator>
<webwork:if test=".=='0'">
<TD> </TD>
</webwork:if>
<webwork:else>
<TD <webwork:if test="$day==.">BGCOLOR="yellow"</webwork:if>
<webwork:elseIf test="$month==thisMonth && today==.">BGCOLOR=#EEAAAA</webwork:elseIf>>
<A HREF="<webwork:url><webwork:param name="'day'" value="."/></webwork:url>"><webwork:property/></A> 
</TD>
</webwork:else>
</webwork:iterator>
</TR>
</webwork:iterator>


Now... this is supposed to be maintainable HOW?

Okay, so my practicle solution to this problem is going to be to avoid tag libs at all cost and use something like Velocity if I can. But also to encourage everyone to go BACK in time to when Tag Libs were first introduced. If you want a calendar, you should write <calendar /> and no more, unless you want to put parameters in for the designers to choose how it looks. More parameters = more control for the designers. You will NEVER be able to separate the view from the controller completely. There's always logic in the view (display this or that, repeat this element how many times, etc.). But still, an attempt to put as much in the tag as humanly possible and only iterate for specific instances would be a good place to start.

Personally, I think all this "generic" (core) libraries are the result that tag libs are a confusing bitch to develop. If we could whip off tags as easily as we can create servlets, for example, that might help.

Okay, end rant (for now).

-Russ