Why Tapestry?
Because Tapestry is the pure spirit of Java Web development. There is nothing better when it comes to presentation layer development, because the creator of Tapestry dared to envision what Java Web development should look like, and made it real. Without political reverances and commercial catch-ups, just as it should be - the Framework for the creative Web developers.
To appreciate what Tapestry gives us let us look at the history of Java Web development.
In the Beginning, there were Servlets
Well, they are still around, as they are the backbone of Java Web development. Because servlet is just a way for a web application developer to put pure Java into a web server.
Servlets are powerful, because they can do everything Java code can do. And they are convenient to deal with, because they hide from developers the complexity of networking and HTTP handling.
But when it comes to producing dynamically a HTML page, servlets are a pain, because you have to write HTML out of your Java code, using statements like println("<p class=\"something\">Bla-bla</p>"). This is boring and error-prone when creating a servlet, but then you'll decide to change your design one day, and this is what will be the real pain, especially if the design isn't trivial. In other words, this problem can be defined as tight coupling between logic (Java code) and presentation (HTML markup).
Then JavaServer Pages came
It was a logical solution, to trust the routine work of converting HTML code of a dynamic page into a servlet's println() statements to a computer. JSP did exactly that: it allowed web developer to add Java code to HTML pages, where needed, and then translated the whole thing into a servlet. This was a really convenient solution, for its time. And especially in those cases when a page contained just a few simple snippets of code.
However, web applications grew more and more complex. They might need to do a lot of calculations, access a database, display information in different ways depending on multiple conditions etc. Java web developers liked their new convenient technology, JSP, and put all the code they needed to be run straight into the scriptlets in their pages. And this recreated the problem which JSP were designed to solve: tight coupling between presentation (HTML markup portion of a JSP page) and logic (Java code in scriptlets).
Let's get rid of Java code!
For a typical designer, those scriptlets with Java code in them were completely unintelligible. And when scriptlets were interwined with HTML in an intricate manner, the whole page would look for a web designer as a nice example of abracadabra. No significant change in design of such a page was possible. On the other hand, Java programmers were less than happy to deal with the pieces of code like this:
<%
for (int i = 1; i <= metaData.getColumnCount(); i++) {
if (metaData.getColumnType(i) == Types.DOUBLE) {
%>
<td align=’right’> <%= formatter.format(resultSet.getDouble(i)) %> </td> <% } else { %> <td> <%= resultSet.getObject(i).toString() %> </td> <% } } %>
Not to mention that many good Java programmers wouldn't actually care what is the difference between <p> and <td> tags.
This is why this movement began: to remove Java code from JSP pages. The idea was that designers felt themselves quite comfortable with HTML tags - so perhaps they will have no problem with some other sort of tags.
In JSP 1.0 it was supposed that Java code could be moved to JavaBean classes which can be accessed from JSP pages with the help of "standard actions", or a special kind of tags like <jsp:useBean> or <jsp:getProperty>. It is not clear though whether designers and programmers became happier when instead of a simple scriptlet, to greet a visitor they would have to write something like this:
<jsp:useBean id="visitor" class="myapp.Visitor" scope="request"/>
Hello <jsp:getProperty name="visitor" property="name"/>!
And also, this approach was quite limited, many important things just couldn't be done without resorting to scriptlets.
This is why JSP 1.1 made the next step in this struggle for separating code and presentation: custom tags, or "custom actions". Now, if you didn't like what was available in JSP by default, you could just write your own library of custom tags and encapsulate into those tags any kind of logic you can imagine.
However, custom tags brought with them a few other problems. First of all, they are not that easy to create. Nothing impossible, but still, working on a project, an average developer wouldn't like the idea of distracting himself from the main work to create a few custom tags. This was more likely to be done by someone else specializing in custom tags development.
Also, if custom tags were used to output some HTML, their code contained the same unintelligible mixture of HTML and Java code which servlets were notorious for.
To simplify JSP development, a set of custom tag libraries named JavaServer Pages Standard Tag Libraries (JSTL) was created, which provided tags for most commonly used functionality.
And still, something important was missing, like a way to conveniently and efficiently access scoped objects and their properties. So another addition to JSP was made, the Expression Language (EL).
And now a more or less complicated JSP page could contain a mix of HTML, JSP directives, standard actions, custom tags and EL expressions - all of them with their different rules and syntax, and not always consistent naming in their APIs. Here is a piece of code which can be found in the "Art of Java Web Development" by Neal Ford:
<%@ taglib uri="http://jakarta.apache.org/taglibs/session-1.0"
prefix="sess" %>
<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
<%@ taglib uri='http://java.sun.com/jstl/fmt' prefix='fmt'%>
<h3>
<sess:attribute name="userName"/>, here is your shopping cart:
</h3>
<TABLE border="1">
<TR>
<c:forEach var="column" items="ID,Name,Quantity,Price,Total">
<th><c:out value="${column}"/></th>
</c:forEach>
</TR>
<c:forEach var="cartItem" items="${items}">
<TR>
<TD><c:out value="${cartItem.itemId}"/></TD>
<TD><c:out value="${cartItem.itemName}"/></TD>
<TD><c:out value="${cartItem.quantity}"/></TD>
<fmt:formatNumber type="currency" var="itemPriceAsCurrency" value="${cartItem.itemPrice}"/>
<fmt:formatNumber type="currency" var="extendedPriceAsCurrency"
value"${cartItem.extendedPrice}"/>
<TD align='right'>
<c:out value="${itemPriceAsCurrency}"/>
</TD>
<TD align='right'>
<c:out value="${extendedPriceAsCurrency}"/>
</TD>
</TR>
</c:forEach>
</TABLE>
If you remeber, we decided to get rid of scriptlets in our JSP pages to achieve clean separation between logic and presentation. How do you think, did we achieve the desired goal? Is this sample of code easy to write and maintain?
Many developers wouldn't think so, and they just continue to use scriptlets. As a result, an unprecedented feature was introduced in JSP 2.0 - the possibility to ban the use of scriptlets in JSP by a configuration setting. A kind of administrative measure in Java web development!
Want to know more? Then read my dissertation "Enterprise Application Development Using Jakarta Tapestry"