feat(template): support xsd:gYear and its relatives as placeholder types

[ashleycaselli]

Closes #670.

A literal placeholder typed xsd:gYear got a plain text field — nothing offered a year, nothing checked one, and "next spring" typed into it was published as "next spring"^^xsd:gYear. The same held for gYearMonth, gMonth, gMonthDay and gDay; only xsd:date and xsd:dateTime had components of their own, with a // TODO add all date time types where the rest belonged.

Why not a date picker

These types name a point on the calendar that is coarser than a date. "2026" and "--05-17" are precisely the values a full date has no way to leave unsaid, so a picker cannot stand in for them. Instead each part gets a control that can only produce something the datatype allows:

Datatype	Controls	Value
xsd:gYear	year	2026
xsd:gYearMonth	year + month	2026-05
xsd:gMonth	month	--05
xsd:gMonthDay	month + day	--05-17
xsd:gDay	day	---17

The year is a number field (spinner, numeric keypad, and a pattern that decides where the input type is ignored); months and days are dropdowns, named rather than numbered.

What it refuses to publish

As much of the point as what it offers, since a nanopublication cannot be edited afterwards:

• A half-entered value is reported, not published. A gYearMonth with a year and no month assembles to nothing and the form says "Please also select a month", rather than emitting "2026-"^^xsd:gYearMonth.
• A day its month cannot have is reported: February 30 says so by name instead of becoming a gMonthDay no calendar has.
• A timezone on a value filled in from an existing nanopublication is carried back out again. Nothing here offers to add one, but dropping one on re-publication would change what the nanopub says.

The value reaches the rest of the form as the single lexical string it always was, so TemplateContext needed no change — it already types the literal from the placeholder's datatype (#564). Keeping the parts behind that string is what lets "May" stay on screen in the moment before a day is picked.

Tests

18 new, 1250 in the suite, all green:

• the lexical forms themselves — what each datatype assembles, what it refuses to assemble, what splits back into the same parts, negative years and five-digit years, and the timezone round-trip;
• the form a user actually gets, through WicketTester: each datatype filled in and submitted, the partial and impossible values reported, a param_ URL seeding the fields, and an untouched optional field staying empty.

Not covered here: xsd:time and xsd:duration, which are clock and interval rather than calendar types and want a different control.

🤖 Generated with Claude Code

https://claude.ai/code/session_018J1JEopfv4icibN6bGkZ1d

---

Update — a bug found in review, fixed in the second commit. A rejected year left the field deaf: every correction was read, stored, and wiped again inside the same request, so the value stayed empty however often it was retyped.

The field carried two updating behaviors — its own, and the KeepValueAfterRefreshBehavior every other item adds on top of one. Both are OnChangeAjaxBehavior, so both run per change, and the second reaches updateModel() when the input it reads is already empty, writing that emptiness over what the first had just stored. A plain text field never shows it: its model takes the same value twice without harm. A value assembled from parts loses the part just set.

The field now keeps one updating behavior — the Ajax round-trip it already makes is what kept values across a refresh, which is all the second was for — and it finds the components to refresh by the value behind the model rather than by the model itself, so a placeholder used in more than one statement stays in step.

Four tests came with it, all driving the Ajax path rather than a form submit, which is where this only ever showed: a corrected year after a rejected one, both parts of a gMonthDay picked one at a time, and a value surviving a change to another field.

Update 2 — the field was still unusable under a template pattern, fixed in the third commit. Entering 46464 where the template's pattern is [0-9]{4} reported Value '46464' doesn't match the pattern for every value entered afterwards, the field refusing corrections until the page was left behind.

The pattern was applied to the stored value rather than to the entry being made. Nothing had judged the first entry, so it was stored; from then on it was the value every check measured, and no correction could replace it, since a failed check is exactly what stops the entry being stored. Checks now assemble the value from what the controls hold.

Three faults of the same kind came out with it, each with a test:

• A value-wide check lived on one part. A pattern that only the month breaks went unapplied when the month was what changed. The template pattern and the impossible-date check now sit on every part, with only the first to report keeping its message.
• Requiring the other part on every change left both parts unstored. Each was rejected for the absence of the one the user had not reached yet, so a gYearMonth could never be completed at all. A part now requires the other only in a request that carries it — a submit — which is how a language-tagged literal requires its tag in LiteralTextfieldItem.
• The day dropdown submitted the position of the day rather than the day. A reader of the field saw the 29th where the 30th was picked, and February 30 passed the check meant to catch it.

Suite: 1257 tests, green.

Update 3 — the year spinner starts at the current year. Stepping an empty number input lands on 1 or -1, a year nobody means and four keystrokes from any they do. The first press of either arrow on an empty year field now fills in the current year; from there the browser's own stepping takes over, counting up and down from wherever the value stands, and a field that already holds a year is left alone.

Typing carries an inputType and using the spinner does not, which is what tells a click on the arrows apart from a 1 the user meant to type. The filled-in year is dispatched as input and change, so it reaches the form rather than only the field.

[tkuhn]

Very nice! Only a few minor things:

• "Update 3 — the year spinner starts at the current year": this didn't seem to work for me
• The dropdown text "Choose One" should rather be "choose month" and "choose day".
• And these month/day dropdowns could be narrower, and are currently slightly less tall than the other dropdowns and text field (just a very minor CSS issue).

Otherwise good to go!