Lukasz Lenart created WW-5694:
---------------------------------
Summary: Deprecate JavaScript client-side validation in the xhtml
and css_xhtml themes
Key: WW-5694
URL: https://issues.apache.org/jira/browse/WW-5694
Project: Struts 2
Issue Type: Improvement
Reporter: Lukasz Lenart
Fix For: 7.4.0
h2. Why
The generated JavaScript validator behind {{[s:form validate="true"/]}} is
legacy on every axis:
* It exists only in the {{xhtml}} theme and {{css\_xhtml}} ({{parent =
xhtml}}). The {{html5}} theme has {{parent = simple}} and never had it.
* It supports eight validators out of the twenty-two in
{{org.apache.struts2.validator.validators}}.
* It reports errors by walking up to a {{TR}} and inserting a row, so it only
works with the table layout. A field with no {{TR}} ancestor sends that walk
off the top of the document, and the handler is {{catch (err) \{ alert(err)
\}}} — a raw JavaScript error instead of a validation message.
* It is driven by the form's {{tagNames}} list, so any input not rendered by a
Struts tag nested inside the form is silently unvalidated. That is WW-2975,
open since 2009 and reproduced unchanged on 7.4.0-SNAPSHOT.
* Test coverage is four golden files and nothing else.
The successor is native HTML5 constraint validation, emitted per field — see
the sibling ticket. That dissolves the WW-2975 root cause rather than patching
it: with constraints on each input there is no central field list for a field
to be missing from.
h2. Scope
Deprecate only. No rendering changes, no behaviour changes.
Following the WW-5510 precedent (commit {{c2a5bfe3c}}):
* {{@Deprecated(since = "7.4.0", forRemoval = true)}} on {{Form.setValidate}},
{{Form.getValidators(String)}} and {{Form.evaluateClientSideJsEnablement}},
*and* on the mirrored {{FormTag.setValidate}}. WW-5510 annotated both the
component and the JSP tag layer; both are public API.
* A {{[strong]Deprecated since 7.4.0[/strong]}} banner inside the relevant
{{[!-- START SNIPPET: ... --]}} blocks in the {{Form}} Javadoc. Those snippets
are pulled into the website by the {{remote\_file\_content}} plugin, so
omitting this leaves the site advertising the feature as current.
* A deprecation banner in the {{form-close-validate.ftl}} header comment — a
template carries no annotation, and anyone who overrode it needs to see it
there.
* No runtime warning. WW-5510 shipped annotations and Javadoc only, and
{{validate="true"}} is opt-in, so every affected user made a deliberate choice
and will be reading release notes.
h2. Traps
* {{Dispatcher}} and {{ValidationInterceptor}} both declare unrelated
{{setValidate}} methods. Do not annotate those.
* {{validate="true"}} is four edits to the rendered form, not one:
{{xhtml/form-validate.ftl}} injects the {{validation.js}} script tag *and*
rewrites {{onsubmit}}; {{xhtml/form.ftl}} overwrites {{onreset}};
{{xhtml/form-close.ftl}} includes the close template. All four must be
described in the docs as deprecated together.
* WW-5510's annotations say {{since = "7.0.1"}} while its fix version was
7.0.3. Use the real target version here.
h2. Documentation
Mark {{core-developers/client-validation-example.md}} deprecated, and note the
deprecation in {{tag-developers/form-tag.md}}. While in
{{core-developers/pure-java-script-client-side-validation.md}}, fix its stale
claim that messages are "not the internationalized version" —
{{ValidatorSupport.getMessage}} resolves through {{DelegatingValidatorContext}}
and {{textProviderFactory}}, so the text is properly i18n'd.
Removal is tracked separately against 8.0.0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
