The Tapestry framework allows Web application authors to define HTML templates, and then combine those templates with bits of Java code via XML descriptors. The latest Tapestry release, currently available as the 4.1 development version, extends the framework's component-centric design to the client, mainly by closely integrating with the open-source dojo toolkit.

While in principle other Ajax toolkits can also be used with Tapestry 4.1, the current release ships with the dojo libraries. Dojo is not just a widget toolkit, but a more general client-side Web framework, and the close integration brings true Ajax-capabilities to Tapestry applications:

• dojo's widget toolkit is now available for Tapestry applications, complementing Tapestry's more modest foundation components. Dojo offers a large—and growing—array of rich-client widgets, such as forms, trees, and grids, as well as layouts and widget effects. Equally important, dojo makes new component creation relatively easy, and newly defined dojo components can take advantage of other dojo features, such as client-side storage, drag-and-drop, and special effects.
• Tapestry's client-side validation framework was replaced with the dojo validation framework:

  All of the validation constraints that can be specified on the server now have client side functional equivalents. Default logic for displaying validation errors/interactions on the client side UI has also been updated a great deal. The old alert box mechanism has been replaced by field decorators that apply CSS rules to your form fields, as well as DHTML dialog boxes displaying summaries of errors.

In addition, Tapestry 4.1 now comes with a JSON-based communication API (JSON is also used extensively in the dojo toolkit):

New component classes and rendering schemes also accompany the API addition, allowing anyone to easily add JSON communication to an existing component or new components.

The most interesting Tapestry 4.1 feature is a new @EventListener annotation that:

Allow[s] people to bind one of their page/component class listeners to virtually any client side widget/html event concievable. The API also supports varying types of listening, such as being able to submit a form when a particular event happens, or simplying using the new BrowserEvent object to determine the client side state when the event happened.

Almost all of the new Tapestry features aim to allow developers to create applications that relegate an increasing amount of processing and display logic to the client, such as validation and component rendering. That design choice may sound reasonable, given the proliferation of more capable, and more standards-compliant, browsers. But, as Martin Fowler argued in his First Law of Distributed Object Design (Don't distribute!), distributed architectures can introduce many additional design complexities.

To what extent is adding AJAX causing distributed headaches?