[ https://issues.apache.org/jira/browse/TAP5-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thiago Henrique De Paula Figueiredo closed TAP5-2645. ----------------------------------------------------- Fix Version/s: 5.7.0 Resolution: Fixed > Java Time API / JSR310 Type Coercers > ------------------------------------ > > Key: TAP5-2645 > URL: https://issues.apache.org/jira/browse/TAP5-2645 > Project: Tapestry 5 > Issue Type: Improvement > Reporter: Benjamin Weidig > Assignee: Thiago Henrique De Paula Figueiredo > Priority: Minor > Fix For: 5.7.0 > > Attachments: TAP5-2645-Documentation.md, TAP5-2645.diff > > > h1. Summary > Add JSR310 / Java Time `CoercionTuple`s to Tapestry. > h1. Goals > With Tapestry 5.5.0 elevating the minimum Java version to 1.8, it should > provide `CoercionTuple`s for the new Java Time API > ([JSR310]([https://jcp.org/en/jsr/detail?id=310)):] > * Add a `CoercionTuple` for all relevant types > * Add specific tuples to reduce possible mismatches > h1. Motivation > Type coercion is deeply ingrained in Tapestry. > And therefore it should be as mature and complete as possible for its Java > version. > The addition of the Java time API is a well thought-out replacement for the > previous limited `java.util.Date`-/`java.util.Calendar`-based approach. > By adding type coercion for the new types we could encourage developers to > use them in their code, instead of working around them missing, or needing to > provide their own implementation. > h1. Risks and Assumptions > None to minimal risk is assumed. > For Tapestry itself, no risk can be assumed. > Existing type coercers won't be changed, only new ones added. > For user projects a minimal risk of duplicate type coercers exist. > Due to the implementation of > `org.apache.tapestry5.ioc.internal.services.TypeCoercerImpl` > user type coercers will override the newly provided ones. > h1. Alternatives > Instead of automatically including the type coercers we could lock them > behind a feature-flag. > h1. Details of Proposed Changes > The Java Time API has well-defined `toString()` methods, so we don't need > explicit `Type.class --> String.class` coercers. > Additional type coercers are needed for type-downgrade (`LocalDateTime.class > --> LocalDate.class`), due to possible parsing exception between different > `String`-based output formats. > Following type coerces will be added: > > {code:java} > * Year --> Integer > * Integer --> Year > * Month --> Integer > * Integer --> Month > * Month --> String (enum) > * String --> Month (enum) > * String --> YearMonth > * YearMonth --> Year > * YearMonth --> Month > * String --> MonthDay (enum) > * MonthDay --> Month (enum) > * DayOfWeek --> Integer > * Integer --> DayOfWeek > * DayOfWeek --> String > * String --> DayOfWeek > * String --> LocalDate > * LocalDate --> YearMonth > * LocalDate --> MonthDay > * LocalTime --> Long > * Long --> LocalTime > * String --> LocalTime > * String --> LocalDateTime > * LocalDateTime --> LocalDate > * String --> OffsetDateTime > * OffsetDateTime --> OffsetTime > * String --> ZoneId > * String --> ZoneOffset > * String --> ZonedDateTime > * ZonedDateTime --> ZoneId > * Instant --> Long > * Long --> Instant > * Duration --> Long > * Long --> Duration > * String --> Period > {code} > h1. Testing > All added functionality will be unit tested. -- This message was sent by Atlassian Jira (v8.3.4#803005)