[jira] [Comment Edited] (WW-2975) client side validation and components with forms

["Lukasz Lenart (Jira)" <ji...@apache.org>]

    [ 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:50 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, 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.


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 {{if (form.elements['myUpDownSelectTag'])}} block;
* with an identical raw input element carrying the same name, it contains nothing at all — 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)