[
https://issues.apache.org/jira/browse/WW-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18107402#comment-18107402
]
Lukasz Lenart edited comment on WW-2975 at 8/24/26 1:51 PM:
------------------------------------------------------------
Triaged 2026-08-24. Miguel's report still reproduces unchanged on {{main}}
(7.4.0-SNAPSHOT), seventeen years on — but the resolution is to retire the
subsystem rather than repair it, so this is being closed as superseded rather
than fixed.
h2. Reproduced
A form whose action declares a {{double}} validator for {{myUpDownSelectTag}},
rendered twice:
* with a nested Struts tag, the generated function contains the expected guard
and validation block for that field;
* with an identical raw input element carrying the same name, the body of the
generated {{validateForm\_doubleValidationAction}} function is nothing but:
{code:javascript}
var errors = false;
var continueValidation = true;
return !errors;
{code}
An empty shell that sets {{errors}} nowhere and always returns true.
The cause is exactly as reported. {{xhtml/form-close-validate.ftl}} iterates
{{attributes.tagNames}}, a list seeded in {{Form.evaluateExtraParams}} and
appended to in {{UIBean.evaluateParams}} _only_ when
{{findAncestor(Form.class)}} finds the form on the component stack. Anything
reaching the form's markup by another route — pre-rendered HTML handed to a
component, a custom tag, an included fragment — is invisible to it.
The second half of the report holds too, at lower confidence since the
repository has no JavaScript test infrastructure to prove it with:
{{addErrorXHTML}} in {{validation.js}} walks {{parentNode}} upward looking for
a {{TR}}, and a field with no {{TR}} ancestor sends that walk off the top of
the document into a {{catch}} that calls {{alert}}. So the error surfaces as a
raw JavaScript alert rather than a validation message.
h2. Why it is not being fixed here
The feature is legacy on every axis. It lives only in {{xhtml}} and
{{css\_xhtml}}; the {{html5}} theme never had it. It covers eight validators of
twenty-two. It reports errors by inserting table rows, so it only works with
the table layout. Its only test coverage is four golden files.
Fixing the {{tagNames}} scope alone would also make things visibly worse for
precisely the case reported here: the field would start being validated, then
fail to display its message and alert a JavaScript error instead.
h2. What replaces it
* WW-5694 — deprecate the JavaScript client-side validator in 7.4.0
* WW-5695 — derive native HTML5 constraint attributes from the action's
validators in the {{html5}} theme, 7.4.0
* WW-5696 — remove the JavaScript validator in 8.0.0
WW-5695 dissolves this report's root cause instead of patching it. Once
constraints ride on each individual input rather than on a generated per-form
function, there is no central field list for a field to be missing from — and
{{tagNames}} itself disappears in WW-5696.
Thanks for the report, and apologies it sat this long.
Recommend closing as _Won't Fix_, superseded by WW-5695.
was (Author: lukaszlenart):
Triaged 2026-08-24. Miguel's report still reproduces unchanged on {{main}}
(7.4.0-SNAPSHOT), seventeen years on — but the resolution is to retire the
subsystem rather than repair it, so this is being closed as superseded rather
than fixed.
h2. Reproduced
A form whose action declares a {{double}} validator for {{myUpDownSelectTag}},
rendered twice:
* with a nested Struts tag, the generated function contains the expected guard
and validation block for that field;
* with an identical raw input element carrying the same name, it contains
nothing at all:
{code:javascript}
function validateForm\_doubleValidationAction() {
...
var errors = false;
var continueValidation = true;
return !errors;
}
{code}
An empty shell that sets {{errors}} nowhere and always returns true.
The cause is exactly as reported. {{xhtml/form-close-validate.ftl}} iterates
{{attributes.tagNames}}, a list seeded in {{Form.evaluateExtraParams}} and
appended to in {{UIBean.evaluateParams}} _only_ when
{{findAncestor(Form.class)}} finds the form on the component stack. Anything
reaching the form's markup by another route — pre-rendered HTML handed to a
component, a custom tag, an included fragment — is invisible to it.
The second half of the report holds too, at lower confidence since the
repository has no JavaScript test infrastructure to prove it with:
{{addErrorXHTML}} in {{validation.js}} walks {{parentNode}} upward looking for
a {{TR}}, and a field with no {{TR}} ancestor sends that walk off the top of
the document into a {{catch}} that calls {{alert}}. So the error surfaces as a
raw JavaScript alert rather than a validation message.
h2. Why it is not being fixed here
The feature is legacy on every axis. It lives only in {{xhtml}} and
{{css\_xhtml}}; the {{html5}} theme never had it. It covers eight validators of
twenty-two. It reports errors by inserting table rows, so it only works with
the table layout. Its only test coverage is four golden files.
Fixing the {{tagNames}} scope alone would also make things visibly worse for
precisely the case reported here: the field would start being validated, then
fail to display its message and alert a JavaScript error instead.
h2. What replaces it
* WW-5694 — deprecate the JavaScript client-side validator in 7.4.0
* WW-5695 — derive native HTML5 constraint attributes from the action's
validators in the {{html5}} theme, 7.4.0
* WW-5696 — remove the JavaScript validator in 8.0.0
WW-5695 dissolves this report's root cause instead of patching it. Once
constraints ride on each individual input rather than on a generated per-form
function, there is no central field list for a field to be missing from — and
{{tagNames}} itself disappears in WW-5696.
Thanks for the report, and apologies it sat this long.
Recommend closing as _Won't Fix_, superseded by WW-5695.
> client side validation and components with forms
> ------------------------------------------------
>
> Key: WW-2975
> URL: https://issues.apache.org/jira/browse/WW-2975
> Project: Struts 2
> Issue Type: Improvement
> Components: Other
> Affects Versions: 2.1.6
> Reporter: Miguel Diaz
> Priority: Major
> Fix For: 7.4.0
>
>
> When form-close-validate.ftl generates the JavaScript validation code, it
> only takes into account the fields that are present in the <s:form> when it's
> processed (via parameters.tagNames).
> There are two problems with this:
> - if for some reason a field is missing, the validation will fail but no
> message will be displayed
> - if one creates a <s:component> that builds a form and gets some fields
> passed to it in a parameter (i.e. receives the HTML generated by some fields)
> then the form doesn't know about the fields so they aren't included in the
> "tagNames" parameter, thus not taken into account for the JavaScript
> validation
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
