Programming Thoughts
Struts 2 - Annotation-based Validation
Redesign Evaluation
Actually reducing Struts 2's arcane configuration
Struts 2 is a popular MVC framework for Java-based web applications but its annotation-based validation doesn't properly work. So, an alternative was created then redesign overcome design limitations. It should be evaluated against its design objectives.
Design Objectives
The Alternate Redesign page stated the objectives of the alternate redesign. Each will be evaluated.
| Objective | Notes | |
|---|---|---|
| Interceptor based | ✓ | A new interceptor is declared in struts.xml and a new entry for any interceptor
stack for Actions that receive forms. |
| Interceptor should be extensible | ✓ | This can only be judged by future extension attempts but the core algorithm calls many, protected functions. |
| Actual adjustment, validation and conversion should be separate classes | ✓ | |
| Annotation should use defaults or be omitted where possible | ✓ | Annotations can be omitted but the need for specific error messages makes some annotation unavoidable. |
| Policies don't apply if the form field value isn't set. | ✓ | |
| Support for non-string fields including conversion errors | ✓ | |
| Maintain support for exisiting string/non-string field pairs | ✓ | |
| Converters should have a reverse conversion function for form formatting | ✓ | These are used in form formatting. |
| Form formatting should be automatic | ✓ | |
| Compatible with manual conversion and validation | ✓ | String form fields without annotations are only set and the Action's validate function has
not gone away. |
| Manual parameter conversion | ✓ | |
| Recognise ModelDriven | ✓ | As per standard behaviour, if the Action implements ModelDriven, the interceptor
uses its model as the form, otherwise the Action is the form. |
| Annotation can configure that messages write to field errors, action errors or even action messages | ✓ | All annotations have a messageType parameter for this. |
| Abandon reliance on Struts UI tags | ✓ | |
| Configuration only in the form field annotations | ✓ | struts.xml for declaring the new interceptor and message resource files, if
annotations use message keys, are the only separate files. |
| Custom conversion and validator annotations should be able to use code in the same form | ✓ | Custom annotations use class references to obtain custom validators and converters, which can even be inner classes. It would be better if lambda expressions could be used but annotations can't use them. |
| A block of code in converters and validators should be able to report one of many error messages | ✓ |
Design Flaws
Despite a column of green ticks, the redesign still has flaws.
- Hardcoded policies - As described in Alternate Interceptor, the set of recognised annotations is hardcoded. Although custom policies are easily written, client supplied annotations would still be better. This will be the subject of a future article.
- Multiple form fields with the same name to non-string array/collection - Field values that fail conversion become conversion errors but multiple values with the same name aren't referenced properly. It's better for a string array or collection to receive the raw field values and manual validation convert them.
Next part
Continued in Form Formatting Example.