Let's continue with a portion of the JSP that would allow an item to be deleted from the shopping cart. For simplicity, we'll assume that there's an object of class LineItem named item and that there's a servlet used for making changes to the shopping cart.

<tr>
  <td> <%= item.getProductName() %> </td>
  <td> <%= item.getQuantity() %> </td>
  <td> <%  String URL = response.encodeURL("/servlet/update-cart?action=remove" +
 			"&item=" + item.getId());
%>
<a href="<%= URL %>">Remove</a> </td> 
</tr>

This clearly shows that in a JSP application, the designer is responsible for "knitting together" the pages, servlets and other elements at a very low level. By contrast, Tapestry takes care of nearly all these issues automatically:

<tr> 
     <td> <span jwcid="insertName">Sample Product</span> </td>
     <td> <span jwcid="insertQuantity">10</span> </td>
     <td> <a jwcid="remove">Remove</a> </td>
</tr>

Because of the component object model used by Tapestry, the framework knows exactly "where on the page" the remove component is. It uses this information to build an appropriate URL that references the remove component. If the user clicks the link, the framework will inform the component to perform the desired action. The remove component can then remove the item from the shopping cart.

In fact, under Tapestry, no user code ever has to either encode or decode a URL. This removes an entire class of errors from a web application (those URLs can be harder to assemble and parse than you might think!)

Tapestry isn't merely building the URL to a servlet for you; the whole concept of 'servlets' drops out of the web application. Tapestry is building a URL that will invoke a method on a component.

Tapestry applications act like a 'super-servlet'. There's only one servlet to configure and deploy. By contrast, even a simple JavaServer Pages application developed using Sun's Model 2 (where servlets provide control logic and JSPs are used for presenting results) can easily have dozens of servlets.