Geoffrey De Smet
2017-01-20 10:14:32 UTC
I was thinking about how to support the time API introduced in Java 8
(JSR-310). It's on the Contributors Wanted page for a long time, and
now we also have a Jira request for it
(https://issues.apache.org/jira/browse/FREEMARKER-35).
(There's also this: https://github.com/amedia/freemarker-java-8 This
doesn't expose the Java API of the objects, but add a few own methods,
most importantly "format".)
I think that we shouldn't support the java.time types specifically. We
hardly want to add 12+ new TemplateModel-s for them
(InstantTemplateModel, DurationTemplateModel, LocalDateTemplateModel,
MonthDayTemplateModel, etc.), and I think that a such complex and
platform specific thing shouldn't be part of the FTL type system
anyway. Consistently with that decision, we wouldn't replicate the
methods of these things with built-ins either (especially as templates
mostly only meant to display these objects). So java.time objects
should just fall into the same category as any random application
specific class. Thus the DefaultObjectWrapper will expose their Java
API-s too, so you can automatically write someLocalDate.year or even
someLocalDate.plusDays(1). (Out-of-the-box you won't be able to pass
in enums though...) What this so far doesn't solve is formatting. For
that, we should improve on how one can format objects of any "random"
class. So the user should be able to configure FM so that instances of
an user-specified class can be formatted with ?string(...), and also
can have a default format specified (similarly to number_format,
date_format, etc.). So it's the same logic that we have for numbers
and pre-java-8 date-s, only extended to any classes.
We still have to "cheat" a bit. If FreeMarker runs on Java 8, it
should pre-configure itself to deal with those 12+ java.time classes
(otherwise the user had to copy-paste some long configuration
fragment). Also we should add a few variation of `.now` that returns
the value with Java 8 types.
What do you think about this approach?
I think you only need 1 new class: TemporalTemplateModel (or(JSR-310). It's on the Contributors Wanted page for a long time, and
now we also have a Jira request for it
(https://issues.apache.org/jira/browse/FREEMARKER-35).
(There's also this: https://github.com/amedia/freemarker-java-8 This
doesn't expose the Java API of the objects, but add a few own methods,
most importantly "format".)
I think that we shouldn't support the java.time types specifically. We
hardly want to add 12+ new TemplateModel-s for them
(InstantTemplateModel, DurationTemplateModel, LocalDateTemplateModel,
MonthDayTemplateModel, etc.), and I think that a such complex and
platform specific thing shouldn't be part of the FTL type system
anyway. Consistently with that decision, we wouldn't replicate the
methods of these things with built-ins either (especially as templates
mostly only meant to display these objects). So java.time objects
should just fall into the same category as any random application
specific class. Thus the DefaultObjectWrapper will expose their Java
API-s too, so you can automatically write someLocalDate.year or even
someLocalDate.plusDays(1). (Out-of-the-box you won't be able to pass
in enums though...) What this so far doesn't solve is formatting. For
that, we should improve on how one can format objects of any "random"
class. So the user should be able to configure FM so that instances of
an user-specified class can be formatted with ?string(...), and also
can have a default format specified (similarly to number_format,
date_format, etc.). So it's the same logic that we have for numbers
and pre-java-8 date-s, only extended to any classes.
We still have to "cheat" a bit. If FreeMarker runs on Java 8, it
should pre-configure itself to deal with those 12+ java.time classes
(otherwise the user had to copy-paste some long configuration
fragment). Also we should add a few variation of `.now` that returns
the value with Java 8 types.
What do you think about this approach?
TemporalAccessorTemplateModel), not 12+.
All those 12+ java.time objects implement the interface Temporal and
TemporalAccessor.
For example, LocalDate implements Temporal and TemporalAccessor
DateTimeFormatter is the class to parse and format (so read and write)
any of those 12 temporal types.
Writing any such type is easy with
DateTimeFormatter.format(TemporalAccessor):
DateTimeFormatter dateTimeFormatter =
DateTimeFormatter.ofPattern("yyyy-MM-dd hh:mm:ss")
// Landed on moon on 1969-07-20
String s1 = "Landed on moon on " +
dateTimeFormatter.format(LocalDate.of(1969,7,20));
// Landed on moon at 1969-07-20 20:18
String s2 = "Landed on moon at " +
dateTimeFormatter.format(LocalDateTime.of(1969,7,20,20,18);
https://docs.oracle.com/javase/8/docs/api/java/time/LocalDate.html
https://docs.oracle.com/javase/8/docs/api/java/time/temporal/Temporal.html
https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html