struts2 - Why use declarative validation?

Question

In struts2 there are basically two methods to introduce validation: you can do it either

• programmatically, or
• declaratively.

Programmatic validation basically involves implementing the interface Validatable on your action class, for which the method void validate(); will need to be fleshed out. In case validations problems are to be reported back to the user there exists a more complex interface ValidationAware.

In declarative validation, each action to validate gets its own validation file called myactionname-validation.xml in which the validators are declared using an XML description language.

---

At the company where I work we are using the programmatic validation principle, with a small sized validation framework (written internally) to help reuse common validator patterns. I have just read in a struts2 book however, that declarative validation is the the preferred way to go. The book gives a lot of instructions on how to setup declarative validation, however it hardly touches the subject of why the declarative way is preferable.

I see some of the general arguments which are at times held in favor of declarative XML-style configuration, but I can't really see them to apply here: changing this configuration (i.e. validation) is something which is tightly coupled with the model processed by the action and the GUI used to modify values on the model. This is not something which needs to be configurable 'on-the-fly' without recompilation.

What arguments are there to use declarative style validation in struts2?

Is it worth it to dive into yet another XML markup dialect and bother with handling of the separate validation.xml files? Isn't it easier to do it programmatically, and maybe even more maintainable as Java source code (or rather your IDE of choice) will provide you with refactoring tools, structured search, etc. whereas XML config support is often tolerable at best?

Answer 1

Declarative validation is more readable, very powerful and customizable. And in a web application well written (good DTO or VO definition, one Action for every logical action to perform), you can share it in many ways.

For example, if you use Visitor validator (to validate a List of objects from JSP), you put the .xml file in the object package (with the object name), not in the action package, and if you use that object in multiple Actions, you write its validation rules once, and reuse it how many times you want.

I'm not a fan of XML configuration, but after several projects in the old way i discovered the full potential of this kind of Validation, and i wouldn't come back.

Take a look at this for some tips you may want to know.

Answer 2

Isn't it easier to do it programmatically [...]

Not really, although it isn't significantly harder, either. Building up error messages is a more-manual process, but meh, most people don't use the full power of what you can do in the XML anyway.

[...] maybe more maintainable [...]

Not really, although it isn't significantly harder, either.

For code bases with code gen IMO building up XML is easier than building Java, but most code bases don't use code gen at that depth.

For producing human-readable documentation, XML and annotations are much easier to process than Java code.

I use an IDE with pretty decent S2 support, I've never thought to myself "If only I'd written this in code it would have been so much easier", and I don't recall doing many, if any, refactoring in my validation that made me wish it was in code instead of XML.

The point is to re-use existing mechanisms when they exist: it's a trivial, known mechanism, integrated in the framework, and everybody working on an S2 app knows how it works.