[
https://issues.apache.org/jira/browse/WW-5694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart updated WW-5694:
------------------------------
Description:
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.
was:
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.
> 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)
