[
https://issues.apache.org/jira/browse/WW-5811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart updated WW-5811:
------------------------------
Description:
h2. Problem
HTML5 constraint derivation ({{struts.ui.html5.constraints}}) maps range
validators to {{min}}/{{max}} only for {{number}} and {{range}} controls.
{{StrutsHtmlConstraintProvider}} deliberately skips the temporal controls, so
{{DateRangeFieldValidator}} (and the new {{localdate}} validator, WW-5816) emit
nothing.
The {{required}} validator has a related gap. {{addRequiredField}} emits
{{required}} only for {{radio}} and {{file}}, because other controls submit an
empty string, which the {{required}} validator accepts. A temporal control
bound to a {{java.util.Date}} (or {{java.time}}) property is different:
{{DateConverter}} turns {{""}} into null, so the server rejects the empty value
just as the browser would. These controls currently get only
{{data-msg-required}}.
h2. Scope
* {{min}}/{{max}} on *{{date}} controls only*, from {{LocalDate}} bounds
({{localdate}}) and {{java.util.Date}} bounds ({{date}}), written as
{{yyyy-MM-dd}}. A {{java.util.Date}} bound becomes its calendar date in the
server default time zone (the zone the submitted value is parsed in); dropping
the time never makes the browser stricter than the server. Years outside
0001-9999 are skipped.
* {{required}} on *all temporal controls* ({{date}}, {{month}}, {{week}},
{{time}}, {{datetime-local}}) from a {{required}} validator, when the bound
property's declared type converts {{""}} to null: {{java.util.Date}} and
subclasses, {{Calendar}}, {{LocalDate}}, {{LocalDateTime}}, {{LocalTime}},
{{OffsetDateTime}}. A {{String}} property gets no {{required}}.
* The provider needs the property type, so {{HtmlConstraintProvider}} gains a
{{default}} {{constraintsFor}} overload carrying it, which delegates to the
7.4.0 method.
h2. Out of scope
{{min}}/{{max}} on {{month}}, {{week}}, {{time}} and {{datetime-local}}: no
built-in converter and range validator pair reads their submitted values
({{datetime-local}} submits without seconds, there is no
{{LocalTime}}/{{LocalDateTime}} range validator, and {{month}}/{{week}} have no
converter). A separate ticket if needed.
Related: WW-5778 (datetextfield in the html5 theme), WW-5810 (java.time support
in datetextfield), WW-5816 ({{localdate}} validator)
PR: [apache/struts#2061|https://github.com/apache/struts/pull/2061], docs:
[apache/struts-site#367|https://github.com/apache/struts-site/pull/367]
was:
h2. Problem
HTML5 constraint derivation ({{struts.ui.html5.constraints}}) maps range
validators to {{min}}/{{max}} only for {{number}} and {{range}} controls.
{{HtmlControlType.supportsRange()}} already includes the temporal controls
({{date}}, {{month}}, {{week}}, {{time}}, {{datetime-local}}), but
{{StrutsHtmlConstraintProvider}} deliberately skips them, because their
{{min}}/{{max}} values need per-control ISO formatting. As a result,
{{DateRangeFieldValidator}} emits nothing.
The {{required}} validator has a related gap. {{addRequiredField}} emits
{{required}} only for {{radio}} and {{file}}, because other controls submit an
empty string, which the {{required}} validator accepts. A temporal control
bound to a {{java.util.Date}} (or {{java.time}}) property is different:
{{DateConverter}} turns {{""}} into null, so the server rejects the empty value
just as the browser would. These controls currently get only
{{data-msg-required}}.
This affects {{textfield type="date"}} (and the other temporal types) today,
and {{datetextfield}} in the html5 theme (WW-5778).
h2. Proposal
In {{StrutsHtmlConstraintProvider}}, map {{DateRangeFieldValidator}} min/max to
{{min}}/{{max}} for temporal controls, formatted per control:
* {{date}} → {{yyyy-MM-dd}}
* {{month}} → {{yyyy-MM}}
* {{week}} → {{YYYY-'W'ww}} (ISO week-based year)
* {{time}} → {{HH:mm}} (or {{HH:mm:ss}})
* {{datetime-local}} → {{yyyy-MM-dd'T'HH:mm}}
Emit {{required}} from a {{required}} validator on a temporal control only when
the bound property's type converts an empty string to null. A {{textfield
type="date"}} bound to a {{String}} property must not get it, because the
server accepts {{""}} there. The provider currently sees only the control type
and the value, so it needs the property type as well.
Requirements:
* Format the bounds the same way the server compares them, so the browser never
rejects a value the server accepts (time zone and truncation for
{{java.util.Date}} bounds)
* Skip the attribute for controls/value types that cannot be represented
exactly, as the numeric path does for fractional {{min}}
* Tests for each temporal control, including {{datetextfield}} (replace
{{Html5ConstraintRenderingTest.testRendersNoRequiredOnADateTextField}}), and
the tag reference updated
Related: WW-5778 (datetextfield in the html5 theme), WW-5810 (java.time support
in datetextfield)
> Derive HTML5 min/max and required constraints for temporal controls
> -------------------------------------------------------------------
>
> Key: WW-5811
> URL: https://issues.apache.org/jira/browse/WW-5811
> Project: Struts 2
> Issue Type: Improvement
> Components: Core Tags
> Reporter: Lukasz Lenart
> Assignee: Lukasz Lenart
> Priority: Major
> Fix For: 7.5.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> h2. Problem
> HTML5 constraint derivation ({{struts.ui.html5.constraints}}) maps range
> validators to {{min}}/{{max}} only for {{number}} and {{range}} controls.
> {{StrutsHtmlConstraintProvider}} deliberately skips the temporal controls, so
> {{DateRangeFieldValidator}} (and the new {{localdate}} validator, WW-5816)
> emit nothing.
> The {{required}} validator has a related gap. {{addRequiredField}} emits
> {{required}} only for {{radio}} and {{file}}, because other controls submit
> an empty string, which the {{required}} validator accepts. A temporal control
> bound to a {{java.util.Date}} (or {{java.time}}) property is different:
> {{DateConverter}} turns {{""}} into null, so the server rejects the empty
> value just as the browser would. These controls currently get only
> {{data-msg-required}}.
> h2. Scope
> * {{min}}/{{max}} on *{{date}} controls only*, from {{LocalDate}} bounds
> ({{localdate}}) and {{java.util.Date}} bounds ({{date}}), written as
> {{yyyy-MM-dd}}. A {{java.util.Date}} bound becomes its calendar date in the
> server default time zone (the zone the submitted value is parsed in);
> dropping the time never makes the browser stricter than the server. Years
> outside 0001-9999 are skipped.
> * {{required}} on *all temporal controls* ({{date}}, {{month}}, {{week}},
> {{time}}, {{datetime-local}}) from a {{required}} validator, when the bound
> property's declared type converts {{""}} to null: {{java.util.Date}} and
> subclasses, {{Calendar}}, {{LocalDate}}, {{LocalDateTime}}, {{LocalTime}},
> {{OffsetDateTime}}. A {{String}} property gets no {{required}}.
> * The provider needs the property type, so {{HtmlConstraintProvider}} gains a
> {{default}} {{constraintsFor}} overload carrying it, which delegates to the
> 7.4.0 method.
> h2. Out of scope
> {{min}}/{{max}} on {{month}}, {{week}}, {{time}} and {{datetime-local}}: no
> built-in converter and range validator pair reads their submitted values
> ({{datetime-local}} submits without seconds, there is no
> {{LocalTime}}/{{LocalDateTime}} range validator, and {{month}}/{{week}} have
> no converter). A separate ticket if needed.
> Related: WW-5778 (datetextfield in the html5 theme), WW-5810 (java.time
> support in datetextfield), WW-5816 ({{localdate}} validator)
> PR: [apache/struts#2061|https://github.com/apache/struts/pull/2061], docs:
> [apache/struts-site#367|https://github.com/apache/struts-site/pull/367]
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
