Programming Thoughts
Struts 2 - Annotation-based Validation
Validation Design is Too Fragile
Simple workflow and pages or don't bother
Struts 2 is a popular MVC framework for Java-based web applications. One of its interesting features is the Value Stack where object properties can be accessed by name but overridden by the same name higher in the stack. This includes form fields that failed conversion or validation. This works fine for simple forms but users expect more sophistication and the validation cycle can't accommodate it.
Inflexible Design
Struts UI tags, as found in Tag Reference,
generate HTML tags but cannot configure every attribute of the HTML tag. If you need such attributes, you must
write your own code to create the HTML tags. For example, the following fragment in current use uses the DATA-*
attributes, which cannot be created using the Struts textarea tag. Another example in working code
is the FORM attribute, where a field's or button's position puts them outside their FORM tag.
<TEXTAREA CLASS="field" STYLE="height: 100px; width: 830px;" ID="qaNotes<s:property value="#loop.index" />" NAME="notes" MAXLENGTH="1000" DATA-INDEX="<s:property value="#loop.index" />"><s:property value="#itemDisplay.notes" /></TEXTAREA>
If reverting to writing HTML tags, this works fine for string and number form fields as the Struts property
tag can display them but the date tag is needed for correct formatting of dates. Alas, the date
tag fails if it reads a failed conversion value as they're strings, not dates.
Further, unusual data types, such as comma separated integers, require a custom type conversion class and typically a configuration file for each affected Action and model. See Type Conversion. Precisely the kind of arcane configuration that annotations are trying to avoid.
Field Errors Only
Validators can only write to field errors, not action errors (or action messages). Field errors,
placed next to the field, can clash with complex, carefully placed layouts or action errors may merely be the
preferred method, especially for pages converted from Struts 1. Struts UI tags will automatically add any
field errors unless the errorPosition attribute is set to none, which is,
strangely, not documented.
Validation is run by a delegated framework, not the validation interceptor itself, so there's no way to fix this by deriving the interceptor class and overriding appropriate methods.
Next part
Continued in Custom Validation is Too Arcane.