Tapestry 5: Building Web Applications

Chapter 1. Introduction to Tapestry

Programming for the Web is very rewarding. Your application, once deployed, becomes available to millions of people, and it doesn't matter which the kind of computers they are using. If they have a reasonably new web browser, they have a good chance of being able to fully appreciate your creation, whether they are running Windows, Linux, Mac OS, or UNIX on their workstation or hand held device.

To become a web developer, one would normally need to be intimately familiar with the strange world of HTTP protocol—requests and responses flying across the globe, special places for storing information like session or application context, and so on. In short, one would have to go to a much lower level of software development.

This change of level is especially striking for those who have had some experience with a Rapid Application Development (RAD) environment, like Borland Delphi or Microsoft Visual Basic. When using such an environment, it seems so natural that when a button is pressed on a form the desktop application is immediately ready to do something in response to the user's action and all you need to do as a programmer is to provide some code that will run in response.

However, when it comes to web development, a developer needs to keep in mind a long chain of low level processes that run before and after he or she is able to do something useful in response to a button press on a web page. Is this a GET or a POST request? How do we extract useful information from the request? How do we store this information? How do we create a response?

Working at that level means a lot of time is spent in solving relatively simple problems. As web applications become more and more popular it becomes obvious that a more efficient, higher level approach to web development is needed.

Nowadays, several solutions are offered to solve this problem on different software development platforms. In the world of Java, the most efficient and elegant solution is presented by Apache Tapestry. Tapestry is an open-source Java web framework, conceived by Howard Lewis Ship and currently developed by a team of devoted Java pundits from around the world.

Why is Tapestry Special?

Tapestry is an example of a framework that was created keeping the developer in mind.

First of all, its paradigm is very close to that of the RAD environment. A button on the Tapestry page has an event handler method associated with it in a declarative way, and the method is invoked when the button is pressed. The Tapestry web developer doesn't need to remember that the button on the page in a user's web browser and the code of the event handler method on the web server can be thousands miles apart, and doesn't need to care about which communication protocol is being used.

This natural approach makes Tapestry significantly easier to learn than any other web development framework, and it makes the process of development much more efficient. However, there are a number of other attractive features, the combination of which makes Tapestry unique.

Tapestry HTML Templates are Free from Obtrusive Instrumentation

Every web application has to deal with HTML in one or another way. No matter what language is used on the server or what intricate logic is employed to produce the page, what actually gets sent to the user's browser is an HTML page. To make that page dynamic, web applications use some kind of HTML template, or specially prepared chunks of HTML markup, and employ some programming logic to fill that template with dynamically generated data, or manipulate HTML in a desired way.

To make this possible, virtually all web frameworks create a tight mixture of HTML markup and some other kind of code, whether it is Java, PHP, VBScript, JSP tags, JSF, ASP.NET components, or something else. Such an approach has a number of significant disadvantages.

First of all, the more complicated the page design and programming logic, the more difficult it is to weave them together. Second, this tight conglomeration of different kinds of code is extremely difficult to maintain and update. Debugging the programming logic of such a page can be quite a challenge.

Contemporary technologies like Sun's JavaServer Faces or Microsoft's ASP.NET rely on specialized development environments to handle the complexities of mixing a dynamic logic with HTML markup, but design capabilities of such specialized environments are unavoidably limited. As a result, the page design remains quite simplistic and less impressive. Code that is automatically generated by these development environments is usually far from being perfect as it has much duplication and is hard to maintain.

For many applications, it often makes sense to have a special team of designers or to use the services of an external team in order to have a professional looking interface. Unfortunately, in most web technologies the conversion of a thoroughly designed page into an HTML template is a one way procedure. The result becomes incomprehensible for any designer not familiar with programming techniques. So when it comes to a significant change in page design, it might be easier to discard the existing page and start from scratch.

Tapestry solves all these problems in the most elegant way. In Tapestry 3 and 4, templates are valid HTML documents that can be easily read and edited by any designer using a common designer's software, without breaking the logic of the page. In Tapestry 5, templates are XML documents, but they are very close to HTML. With minor reservations, all the advantages of the previous versions apply to them too. The main point is that all versions of Tapestry provide the highest possible level of separation between HTML markup and programming logic.

Custom Components are Very Easy to Create

The use of components allows you to significantly increase the productivity of web development—this is why all the new frameworks, including Tapestry, JavaServer Faces, and ASP.NET are component-based.

However, the choice of core components that come with the framework is always limited, and it is important to give developers an opportunity to create their own custom components. Naturally, such an opportunity is provided by all component-based frameworks, but the level of effort required to create a custom component differs from framework to framework quite significantly.

For instance, to create a custom JavaServer Faces component, the developer needs to know the intricate inner structure of the framework quite well, so this is a task for advanced developers only.

In Tapestry, however, creation of custom components does not require any advanced knowledge, and is perfectly possible for beginners. We will be creating non-trivial custom components in Chapter 8 of this book.

AJAX and DHTML, but No JavaScript Coding

Contemporary web applications are unthinkable without attractive and clever features powered by JavaScript and are commonly known as DHTML and AJAX. However, JavaScript has browser incompatibilities. So Tapestry comes up with a number of components that make the miracles of AJAX available to the application, but, fortunately for developers, all JavaScript is thoroughly hidden inside the framework. AJAX-enabled components are as easy to use as any other Tapestry component, so you can make your application Web 2.0-ready without ever seeing a single line of JavaScript code. Well, at least this is true for the previous version of the framework, 4.1. As of this writing, the AJAX features are currently under development (and will likely be in a finalized state by the time you read this), but it is promised that they will be even more powerful and easier to use than in Tapestry 4.1.

User Input Validation Works Like Magic

User input validation is a must for almost every web application, as users are mere mortals and will always try to submit some erroneous data. A friendly application should clearly explain to the user exactly which piece of input is wrong, but creating an input validation and error reporting subsystem can require quite a lot of work.

Tapestry 4 already had a powerful built-in infrastructure for input validation, but in Tapestry 5 it goes much further. You as a developer will have to do very little, usually simply declaring what exactly you want, while your application will not only clearly mark the erroneous fields, but also automatically display an appropriate message in the language preferred by the current user.

Built-In Internationalization Support

A Java platform itself provides substantial support for internationalization and localization but, in Tapestry we do not need to know the details of that support. We just use a few simple hooks provided by the framework to have our application displayed in as many different languages as we wish.

It is actually quite amazing to see how one mouse click totally changes the language of the application. Everything—text, images, different controls, suddenly begin to speak in a foreign language! It is an impressive feature, considering how little we have to do to enable this flexibility.

Inversion of Control Made Easy

Inversion of Control (IoC) and Dependency Injection are amongst the most popular software development paradigms these days, and they deserve their popularity. In simple terms, Inversion of Control allows developers to save effort and time by allowing some other software to take care of different routine things and provide them services whenever needed.

However, to use the benefits of Inversion of Control in an application, one might need to learn and use an additional framework like Spring. Not in Tapestry though.

Tapestry has an Inversion of Control subsystem of its own, and quite a good one. As a result, Tapestry applications contain very little Java code. All you need to write is business logic while all the infrastructure issues are handled automatically. Aditionally, the Tapestry 5 IoC container additionally provides an opportunity to implement and enforce some of the best design patterns, again, with absolute minimum code serving this purpose.

Spring framework is very popular, and working on a large-scale enterprise application, we often need to make use of some sort of back end, implemented in Spring. Thankfully, Tapestry has a special subsystem for integration with Spring. Using this subsystem in my work, I had an impression that it is easier to use Spring beans in Tapestry than in Spring itself.

More or less the same can be said about integration with another very popular framework, Hibernate. There is a special subsystem in Tapestry responsible for this integration and it is very easy to use.

To summarize, Tapestry is a mature contemporary web development framework with all the features that would be expected from such a framework and with all the power of Java platform to support it. But additionally, Tapestry is based on a unique, developer-friendly paradigm, which makes it especially easy to learn and use.

Why is Tapestry Special?

Tapestry is an example of a framework that was created keeping the developer in mind.

Tapestry HTML Templates are Free from Obtrusive Instrumentation

Custom Components are Very Easy to Create

For instance, to create a custom JavaServer Faces component, the developer needs to know the intricate inner structure of the framework quite well, so this is a task for advanced developers only.

AJAX and DHTML, but No JavaScript Coding

User Input Validation Works Like Magic

Built-In Internationalization Support

Inversion of Control Made Easy

However, to use the benefits of Inversion of Control in an application, one might need to learn and use an additional framework like Spring. Not in Tapestry though.

Is Tapestry the Savior in the World of Java Web Development?

Java technology is traditionally strong on the server side. However, in the last couple of years one might notice some kind of stagnation in the area of Java web development. To explain what I mean, I will need to show you a brief history of Java web development.

In the first stage of web development, it was typical to have some code that a web server could invoke to produce dynamic content. The traditional solution is to have a program written in Perl or C and to invoke it through a CGI interface. The Java solution was different however, and that solution was rather advanced for its time. Java code was running on the server as a servlet, a kind of plug-in maintained by a servlet container.

The servlet way was superior because it ensured higher scalability, but perhaps even more importantly from the developer's point of view, a servlet developer could spend more time writing application-specific code, since many of the lower level issues were handled by the servlet container. At that time, Java technology was ahead of the rest of the web development world.

The next generation of web technology was about embedding pieces of code into an HTML page in order to make it dynamic. You can see this approach in JSP, ASP, PHP and ColdFusion.

Again, Java technology was ahead, because JavaServer Pages took special care about separation between the application code and its presentation logic. Ideologically fortified by Model-View-Controller design pattern, this approach culminated in Apache Struts framework.

Basically, a Struts application is a traditional servlet/JSP application, but this framework offered a number of efficient solutions for common problems of web development. Struts developers could avoid reinventing the wheel and reuse existing solutions by modifying them with application-specific code. This significantly increased the efficiency of large-scale web development, and Struts framework became extremely popular, once again ensuring the leading position of Java technologies.

However, around the same time Microsoft came up with an alternative technological solution, ASP.NET. This was a component-based approach which was supported by a sophisticated integrated development environment (IDE), Visual Studio, ASP.NET resembles RAD solutions that brought desktop development to a new level of productivity some years ago. An ASP.NET developer can drop a few components on the page, set their properties in a visual property editor and run the application—all in just a few seconds.

This is when the feeling appeared that the Java approach is not quite the best anymore. ASP.NET was quickly gaining popularity, while the mainstream Java approach was exemplified by a Struts application, not component-based, and was still quite a low-level solution.

The Java world tried to retaliate by creating JavaServer Faces specification. Externally, it resembles ASP.NET, but is built on top of the existing Java-specific solutions.

JSF is supported and promoted by major software vendors like IBM, Oracle, and BEA, and it's implemented in their state-of-the-art commercial IDEs. Its approach was very similar to the Microsoft approach, but somehow JavaServer Faces didn't gain the popularity it was expected to gain. Maybe that is because to create the JSF specification, so many different parties had to come to a compromise.

Or maybe the problem is in the fact that the JavaServer Faces specification is created using existing Java solutions and has inherited their weaknesses. For example, JavaServer Pages technology, used by JSF to render pages, was very sound for its time, but a JSP page can easily become an unintelligible mixture of HTML, standard tags, custom tags, and EL expressions. Also, JSF has some older features from Struts, like its navigation configured in a lengthy XML file. As a result, JSF technology is difficult to comprehend, learn and work.

Or perhaps the problem with JSF is that it mimics so closely the Microsoft solution, while the Java world has its own laws, and something that is good for Microsoft might not be equally good here?

My point is that if we look at Tapestry, the framework that was never supported or promoted by billionaire corporations, we might notice that it can easily compete with the most recent versions of ASP.NET in many respects.

Features like code-behind in ASP.NET that allows the separation of code of the page from its template, is an integral part of Tapestry from the very beginning of the framework. In fact, in Tapestry you cannot just mix code and HTML since all Java code goes into the page class.

In fact, many solutions that are promoted as advanced features of ASP.NET can be found either in the core Tapestry framework or in a library of custom Tapestry components, such as Tacos.

It may well happen that with time, as more people realize the benefits of Tapestry, it might become the model for the next generation of a Java web framework specification.

However, nothing is perfect, and Tapestry has its downsides too. One of them is the fact that the framework's development goes ahead in huge steps, which makes the next version very different from the previous one. To fully appreciate what this means, let's have a look at a brief history of Tapestry.

The Journey of Tapestry from 3 to 5

Tapestry was originally conceived by Howard Lewis Ship around the year 1999, but the early versions of the framework are not widely known.

Tapestry 3 became the first well known version, and I used it for my first Tapestry application that I created in the summer of 2005. Tapestry was a great relief after my experience with servlets and JavaServer Pages. Its approach was very easy for me to understand, maybe because in the past I had plenty of experience with Borland Delphi, a very popular Rapid Application Development environment.

However, some features were not fully implemented in Tapestry 3. Most notably the validation subsystem was somewhat deficient. Also, some obvious components were missing, and I had to create a number of custom components myself (although that wasn't too difficult, frankly speaking). All in all, I was very happy that I had learned Tapestry, and I was going to use it for years.

However, when Tapestry 4 appeared in January 2006, it was so different that I had to learn the framework again. It was not a problem though as Tapestry 4 had streamlined and made many features easier than in the previous version. Most significantly, Tapestry 4 was built on top of Hivemind, another Open Source project created by Howard Lewis Ship. Hivemind made it possible to easily extend and configure Tapestry, but most notably, it allowed users to inject anything into the page, as Hivemind was (and is) quite a capable Inversion of Control container. Also, Tapestry introduced a brand new user input validation subsystem, flexible and easy to use.

On a negative note, Tapestry 4 was not compatible with Tapestry 3, and upgrading an application to the new version required a substantial amount of effort.

Tapestry 4.1 became another major step in the development of the framework. It came with Dojo JavaScript toolkit built into it, and as a result it made AJAX functionality easily available to Tapestry developers. It looks like version 4.1 will stay here for a while and allow many people to benefit from using it for building their web applications. It still has a few places where it could be streamlined or enhanced, but, it is a powerful and developer friendly framework.

Very soon however, it became clear that Howard Lewis Ship was working on a completely new, fifth version of Tapestry, and that version was not just a step, but a quantum leap forward. Tapestry 5 was created from scratch, and on one side, it incorporated all the best ideas accumulated by Tapestry developers over the years, while on the other side it got rid of those solutions that proved to be obsolete or inefficient. Needless to say that neither Tapestry 3 nor Tapestry 4 were compatible with Tapestry 5, although their approach was very similar.

Tapestry 5 is a truly contemporary framework. It was specifically designed to be extremely developer friendly. Page classes are now POJOs (Plain Old Java Objects), since they do not need to inherit from any framework-specific classes, and we have more freedom in choosing how to implement them. They are easy to test too. To give Tapestry hints on what we expect from it, we use Java annotations, and the framework adapts to our requirements instead of expecting us to adapt to its rules.

Tapestry 5 comes with new powerful components. Their rich functionality can be easily adjusted for a specific application's needs, and so there will be significantly fewer cases when we need to create custom components. Creating custom components is even easier now than it was before, so our creativity is not limited in any way.

Tapestry 5 is significantly faster than the previous versions too. Not to say that those were slow. Tapestry 3 and Tapestry 4 applications are as fast as any other Java web application. All versions of Tapestry were created with great scalability in mind, which means that Tapestry applications can work under a significant workload—say, thousands of visitors using the application simultaneously.

I am not going to list here all the novelties of Tapestry 5 as we are going to learn them in the course of this book, but I encourage you to visit the Tapestry website (http://tapestry.apache.org) and read what the creators of the framework write about the new version. In general, it is significantly easier to learn to work with and efficient too.

It is also stated by its creators that Tapestry 5 will become a stable long-term platform for the future development of the framework. They have taken special care to ensure that the future versions of the framework will be backward compatible.

So it looks like you came to Tapestry just in time!