LocalD*TextField has the purpose to offer some convenience constructors
and implementing ITextFormatProvider,
If you allow people to use a custom converter, this class loses its purpose.
Sven
On 22.09.23 04:47, Maxim Solodovnik wrote:
On Wed, 13 Sept 2023 at 05:13, Sven Meier <s...@meiers.net> wrote:
Hi Maxim,
it will be hard to make that suitable for different projects with
different requirements:
In Arabic sometimes dates are written in Latin digits, so we can't call
#withDecimalStyle in general.
We could add other constructors with IConverter argument, but then
Local*TextField wouldn't add anything that you can't do with your own
TextField subclass.
Maybe add this?
protected DateTimeFormatter configure(DateTimeFormatter formatter) {
return formatter; }
Just have checked LocalDateTextField and LocalDateTimeTextField both
has method createConverter
Which actually doesn't create converter ...
Maybe I it worth to refactor both to
- remove final from converter
- create and set converter in `createConverter` method
This way users can tune converter on creation? :)
Once again, rolling your own component might be simpler.
Regards
Sven
On 12.09.23 03:54, Maxim Solodovnik wrote:
Hello All,
Sorry for the long email
While working on PR for wicket-bootstrap [1] i have test multiple
locales and find out LocalDate*Time*TextField doesn't behave well with
locales like Persian/Arabic (those with custom digits)
All classes `Local*TextField` from datetime package [2]
have `TextFormatConverter converter` as private member
With constructors accepting `String pattern` and `FormatStyle`
With locales uses different numeral systems (like Arabic) this doesn't
work well :(
Here are some examples
All below can be checked with `jshell` (and/or `bootstrap-samples` from [1])
`LocalDate.of(2020, 11,
5).format(DateTimeFormatter.ofPattern("yyyy/M/d").withLocale(Locale.forLanguageTag("fa")).withDecimalStyle(DecimalStyle.of(Locale.forLanguageTag("fa"))))`
> "۲۰۲۰/۱۱/۵"
Let's parse this one using DateTimeFormatter like it is being created
in current Wicket code:
`DateTimeFormatter.ofPattern("yyyy/M/d").withLocale(Locale.forLanguageTag("fa")).parse("۲۰۲۰/۱۱/۵")`
> Exception java.time.format.DateTimeParseException
Missing `withDecimalStyle` might help but unfortunately
tempus-dominus-v6 [3] produces dates like "2003/۱۱/5" (please note
digits in mixed numeral systems are present)
Surprisingly the above works well with SimpleDateFormat:
`LocalDate.ofInstant(new SimpleDateFormat("yyyy/M/d",
Locale.forLanguageTag("fa")).parse("2003/۱۱/5").toInstant(),
ZoneId.systemDefault())`
please NOTE SimpleDateFormat doesn't honor RTL
It will produce wrong date for
`new SimpleDateFormat("d/M/yyyy",
Locale.forLanguageTag("fa")).parse("۲۰۲۰/۱۱/۵")`
BUT correct date with
`new SimpleDateFormat("yyyy/M/d",
Locale.forLanguageTag("fa")).parse("۲۰۲۰/۱۱/۵")`
So I believe wicket code need to be improved:
- `withDecimalStyle` *might* be added
- internal date/time formatter should be accessible for the user (so
it can be twicked)
WDYT?
[1]https://github.com/l0rdn1kk0n/wicket-bootstrap/pull/1002
[2]https://github.com/apache/wicket/tree/master/wicket-extensions/src/main/java/org/apache/wicket/extensions/markup/html/form/datetime
[3]https://getdatepicker.com/6/
