docs: HTML5 constraint validation, deprecate the JavaScript validator - #326
Open
lukaszlenart wants to merge 5 commits into
Open
docs: HTML5 constraint validation, deprecate the JavaScript validator#326lukaszlenart wants to merge 5 commits into
lukaszlenart wants to merge 5 commits into
Conversation
Rewrites client-side-validation.md around the html5 theme's new HTML5 constraint-validation attributes (struts.ui.html5.constraints), including the never-false-reject rule, the full validator-to-attribute mapping, the trim="false"/caseSensitive="true" conditions on stringlength/regex, the never-change-the-type rule, data-msg-* hooks, the requiredLabel/required distinction, and the swappable HtmlConstraintProvider extension point. Deprecates the older generated-JavaScript client-side validator (xhtml/ css_xhtml themes, <s:form validate="true">) per WW-5694, removed in 8.0.0 per WW-5696: deletes pure-java-script-client-side-validation.md, repoints its inbound links (xhtml-theme.md, css-xhtml-theme.md, ajax-client-side-validation.md) to the deprecated section of the rewritten page, adds deprecation banners to client-validation-example.md and form-tag.md's validate attribute. Drops the deleted page's claim that client-side messages are not internationalized: ValidatorSupport.getMessage resolves through DelegatingValidatorContext and textProviderFactory, so they always were. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ault flip The shipped javadoc and default.properties deliberately say the struts.ui.html5.constraints default is "expected to flip in a future major release" rather than naming 8.0.0, since the release version is chosen at release time from the accumulated semver impact. The docs page asserted "in Struts 8.0.0" instead, which is a firmer commitment than the code itself makes. Softened to match the code's wording, with WW-5696 linked so the claim stays traceable. Also makes every other "removed in 8.0.0" claim (the JS validator's removal) cite WW-5694/WW-5696 inline rather than floating as a bare assertion. Naming 8.0.0 for that removal is kept as-is: it's a major-version removal, already committed to in Form.java's own @deprecated(since = "7.4.0", forRemoval = true) javadoc, and WW-5696 is filed against it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…rim note The regex row promised pattern whenever text-entry, caseSensitive="true", trim="false" and ECMAScript-safe held, but StrutsHtmlConstraintProvider has a fourth gate: email and creditcard validators are excluded even then, since both extend RegexFieldValidator but carry grammars the browser doesn't share. Also generalizes the trim="false" explanation: StringLengthFieldValidator.trim defaults to true just like RegexFieldValidator.trim, so minlength/maxlength are emitted just as rarely as pattern is, for the same reason (server measures/ matches the trimmed value, browser sees the raw one). The page previously warned about this only for pattern, which understated stringlength's own reach. Reworked into one shared paragraph covering both. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…er blocks) The previous sentence said a stringlength validator with maxLength="4" would reject "abcd " server-side after trimming — backwards. Trimmed to "abcd" (4 chars), StringLengthFieldValidator.validateValue only rejects when trimmedLength > maxLengthToUse, and 4 > 4 is false, so the server accepts it. The paragraph exists to show the server-accepts/browser-blocks asymmetry that makes emitting the constraint attribute risky if trim isn't false; an example asserting the opposite direction illustrated nothing. Corrected to state the server accepts "abcd " while a browser maxlength="4" would stop the fifth character from ever being typed, matching the direction of the retained [a-z]+/"abc " regex example alongside it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Staged site is ready at https://struts.staged.apache.org/ |
The page was folded into client-side-validation.md as a deprecated section,
which frees the URL but 404s external inbound links to a page that has been
live for years. Internal links were already updated; this covers the ones we
do not control.
Uses .htaccess rather than leaving a stub page behind, following the existing
"downloads was renamed to releases" precedent in the same file: no orphan page
in the nav tree, and the reader lands on the section rather than on a pointer
to it. Matches both the extensionless and .html forms.
Issued as a permanent (301) redirect. The fold-in is not going to be undone,
and 301 is what consolidates the old URL's link equity onto the new section;
the surrounding rules only default to 302 because none of them ever specified.
Pins the target heading's anchor explicitly with {#...} instead of relying on
kramdown's auto_ids. The generated id is identical today, but eight internal
links and the redirect now depend on it, so it should not be a side effect of
the heading's wording.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
lukaszlenart
force-pushed
the
docs/html5-constraint-validation
branch
from
August 25, 2026 09:16
38c86ee to
9f79cab
Compare
|
Staged site is ready at https://struts.staged.apache.org/ |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Companion documentation for apache/struts#1865, which implements WW-5695 (derive HTML5 constraint attributes from validators) and WW-5694 (deprecate the generated-JavaScript validator).
Merge this only when #1865 merges — it documents 7.4.0 behaviour that does not exist yet.
What changed
core-developers/client-side-validation.mdis largely rewritten. It used to be a short page whose main job was to point at two sub-pages; it is now the primary reference for the feature, covering:struts.ui.html5.constraints=true, off by default,html5theme only — there is no per-formvalidate="true"opt-in)typerequiredsplitting across two validators that behave differently,minlength/maxlengthandpatternboth needingtrim="false"(not the default), and\s/\Sbeing excluded from the portable-regex allowlistdata-msg-*attributes, and the fact that Struts ships no JavaScript that reads themrequiredLabelis unrelated to therequiredattribute — a long-standing point of confusion the old page raised but never resolvedHtmlConstraintProviderextension point as the escape hatch for every limitation abovepure-java-script-client-side-validation.mdis deleted and folded into that page as a clearly-marked deprecated section. No internal links to it remain.The
xhtml,css_xhtml, andform-tagpages get deprecation notes pointing at the replacement.ajax-client-side-validation.mdgets one clarifying line: it is unaffected by any of this.Accuracy
Every claim was checked against the implementation rather than the design doc — the control-type lists come from
HtmlControlType, and the constant names and defaults fromStrutsConstants/default.properties. The commit history reflects three corrections made when the code and spec diverged during review.Removed page keeps its URL
pure-java-script-client-side-validationis folded intoclient-side-validation.mdrather than kept as a stub, sosource/.htaccessredirects the old URL to the new section — following the existing "downloads was renamed to releases" precedent in the same file. It matches both the extensionless and.htmlforms, and the target heading now pins its anchor explicitly with{#...}rather than depending on kramdown'sauto_ids, since eight internal links and the redirect all rely on it.The redirect is issued as
permanent(301): the fold-in will not be undone, and 301 is what consolidates the old URL's link equity onto the new section. The surrounding rules default to 302 only because none of them ever specified a status.🤖 Generated with Claude Code