Technical Topics

I have never liked the way Tapestry displays validation errors. First of all the red cross that is displayed after fields in error is destroying the layout of my forms far too often. The carefully arranged fields and labels are jumping around just to make place for the image. Secondly I really don't like the "error bubbles" that appear when client side validation causes errors. They sometimes appear surprisingly, often are covering important content of my sites and sometimes disappear too quickly for reading the error message they are supposed to display. In this topic I'll describe how to customize Tapestry in a way that I found more convenient.

Alternative Error Message Representation

After having described the things I do not like about Tapestry's way of displaying error messages, I am now describing the alternatives I chose:

• The img-Tag for displaying the red cross must not appear in the site's HTML-markup anymore. Simply making it invisible by CSS is not sufficient.
• The only good thing about the error bubbles is that they have a visual connection to the field, where the error occured. As an alternative the error message shall be displayed in the label-tag that belongs to the field. To preserve enough space for the error message, the label is placed above the field it belongs to, not left of it.

Implementation as a "Mixin"

The above mentioned requirements are implemented as a so called Mixin [External: Component Mixins] for the form-component. The advantage is to have everything in a single place and not spread over several parts of the code. Additionally it is easy to switch back to Tapestry's default behavior by simply erasing the mixin from the template file. Further details about the mixin can be found in the description and the comments of the source code.

Custom Implementation Of ValidationDecorator

To eliminate the red cross and to correctly show the error messages at the right place a custom implementation of the interface org.apache.tapestry5.ValidationDecorator is needed [External: Interface ValidationDecorator] As a base class for implementations Tapestry provides the class org.apache.tapestry5.BaseValidationDecorator [External: Class BaseValidationDecorator] In this class all methods are empty and can be overriden to do what is desired. The interesting methods for our implementation are "insideLabel" and "insideField". How the implementation is added to the application will be explained in section "Gluing everything together: The mixin class".

...

Some styling with CSS

To really position the labels above the fields and for an overall coherent layout of forms a small piece of CSS is necessary. How this is added to the web pages will be explained in section "Gluing everything together: The mixin class".

...

JavaScript for displaying the error messages during client side validation

Client side validation is achieved using JavaScript (what else). The core features can be used as is. Only the way error messages are displayed has to be customized. To do so the methods "initialize", "removeDecorations" and "showValidationMessage" in Tapestry's "Tapestry.FieldEventManager" must be overridden. This is done by the following piece of JavaScript. How this is added to the web pages will be explained in section "Gluing everything together: The mixin class".

...

Gluing everything together: The mixin class

All required features are provided by the three afore mentioned files. The only thing left is to contribute them to the webapp at the right place/time. That's what the mixin class is for. What is contributed when and under which condition is explained in the source code.

...

Usage

To use the mixin download the source code files and move them to the right packages. The files ErrorMessageCustomizer.java, ErrorMessageCustomizer.js and ErrorMessageCustomizer.css must be located in the mixins-package (or a sub package thereof). It is important that they are all located in the same package. The file CustomValidationDecorator.java can be moved to any package of your choice. Now add the apropriate package declarations to the java files and you're done.

Credits go to

• AndyB from the Tapestry Maillist for posting his JavaScript. I myself did it a bit different. But without his valuable input I would not have made it, given my limited JavaScript skills. [External: AndyB's Post]
• jumpstart.doublenegative.com.au team for their detailed explanation of a custom form component to get rid of the error bubbles. [External: "No Validation Bubbles" on jumpstart.doublenegative.com.au]

My development machine is located behind a proxy. Therefore to load dependencies from the web Maven has to pass the proxy. That's what the section "proxies" in the settings.xml is for. The configuration looks as follows:

...

Recently I have switched from JUnit to TestNG. Thanks to the Eclipse plugin the conversion of the test code is no more work than just pressing a button. The assertion-methods are converted to those supplied by the class org.testng.AssertJUnit. But I considered this an intermediate solution and wanted to use the assertion-methods supplied by the class org.testng.Assert. That meant a little challenge. In JUnit the order of parameters for assertions with two parameters (e.g. assertEquals) is "expected", "actual". In TestNG it is just the other way round. For that reason the parameters needed to be flipped.

...