A rethink for the DWR/Spring Ajax connection

Earlier this year, Eric Speigelberg set out to provide server-side validation of client-side HTML forms using Ajax. There are a lot of good reasons to do this, not the least of which is being able to keep validation in one place (the server) and in one language (Java), rather than having a whole separate validation code base to run in the browser:

Although client-side validation, using JavaScript, provides immediate feedback and an enhanced user experience, it has many disadvantages such as being tedious and error-prone to develop, being hard to test, and leading to fragile code. Inconsistent implementations across different browsers and the fact that a user can disable JavaScript is enough to conclude that client-side validation alone is not sufficient. Although a hybrid approach of performing validation on both the client and server may seem like a good solution on the surface it doesn't take long to realize that the increased development time, duplication of logic, and inevitable maintenance and testing problems quickly outweigh the advantages.

So, in Ajax Form Validation Using Spring and DWR, Eric showed how to use Direct Web Remoting(DWR) as the heart of a system that could run server-side validation of each form element as the user enters data.

Now, after nine months, Eric has found that there are better ways to accomplish this, and in our Feature Article,Ajax Form Validation Using Spring and DWR, Revised, he shows off an improved approach:

Few non-trivial software designs get it right the first time. This design has been running in production systems for over a year (its publication is approaching the ten-month mark), and has shown some limitations. This article discusses the emerged limitations and then presents an improved design that not only addresses the limitations but provides added functionality.

In Java Today, Neal Gafter has updated his Closures for the Java Programming Language specification to version 0.5, and blogs about the most prominent change in the new spec, Restricted Closures. "The Closures for Java specification, version 0.5, contains a special marker interfacejava.lang.RestrictedClosure. When a closure is converted to an interface that extendsRestrictedClosure, this prevents the closure from doing certain operations. Specifically, it prevents accessing mutated local variables from an enclosing scope, or using abreak, continue, or returnto a target outside the closure. The idea is that APIs that are intended to be used in a concurrent setting would want to receive restricted rather than unrestricted closures to prevent programmers from shooting themselves in the foot."

Community members are encouraged to take the Mobile & Embedded Community survey. "It has been more than 12 months since the launch of the Community and we know that Community membership is up, there has been tremendous growth in new projects and the forums are active. But we won't know how well we're doing until we hear from you. So please take the Community survey and let us know!

The latest edition, issue 149 of the JavaTools Community Newsletter is out, with tool-related news from around the web, an invitation to join the Soy Latteproject to bring the BSD Java SE 6 to Mac OS X, an announcement of a new Tools community project, and a Tool Tip on checking out selected folders from Subversion.

Do you hear them? Do you hear The Winds of Change? In today's Weblogs, Joshua