[
https://issues.apache.org/jira/browse/WW-5694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart resolved WW-5694.
-------------------------------
Resolution: Fixed
> 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
> Priority: Major
> Fix For: 7.4.0
>
>
> h2. Why
> The generated JavaScript validator behind the form tag's {{validate="true"}}
> attribute 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 a bare catch that calls
> {{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 bold "Deprecated since 7.4.0" banner inside the relevant START SNIPPET /
> END 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)
