Hi, There may be compatibility issues as the new coercions use the type `Long` as intermediate value.
I.e. Long -> LocalDate -- it currently treats long as nanos, but what if Long is in milliseconds? Same with Duration (millis) and Instant (millis). If we apply these coercions unconditionally we may break existing applications who have coercions defined in their own modules. For Strings it's probably fine as every type uses its own format, so I'd suggest we remove Lond from the list of contributions. And maybe add the new conversions conditionally: it's fine to have them enabled by default, but we should at least provide a symbol to disable them? On Wed, Oct 21, 2020 at 3:00 PM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > On Fri, Oct 16, 2020 at 5:01 AM Ben Weidig <b...@netzgut.net> wrote: > > > Hi, > > > > Hello! > > > > it would be great to see the Java Time API better integrated into > Tapestry, > > so I've started adding type coercers. > > > > As with my JSON improvements, I've prepared a short proposal to highlight > > the intentions and ramifications better. It's included in the ticket, > which > > also already has a patch: > > > > Proposal: > > https://gist.github.com/benweidig/e0e7c9a26f3805e610c4511a0a15b9e3 > > > > Ticket: https://issues.apache.org/jira/browse/TAP5-2645 > > > > Compare: > > > > > https://github.com/apache/tapestry-5/compare/master...benweidig:typecoercer-jsr310 > > > This is awesome! Thank you very much again for another great pull request! > If you agree, I shall merge it into master this week. > > > > > > > > I've excluded the more "unusual" types in java.time.chrono, like > > JapaneseDate etc. > > But if you think they should be included as well, I could create an > > additional patch. > > > > Feedback is always welcome. > > > > Cheers > > Ben > > > > -- > > > > Netzgut GmbH > > > > > -- > Thiago > -- Dmitry Gusev AnjLab Team http://anjlab.com
