It's time to make a new release at the end of December (early January
maybe). So far not much have piled up, to say the least:
- FREEMARKER-104: More helpful log and error messages (especially, no
NullPointerException cause exception logged during FreeMarker XPath
support initialization) if no XPath implementation is available
because Java 9 modules don't allow accessing the internal Xalan
that's stored under com.sun packages. (The messages now recommend
adding Apache Xalan or Jaxen as dependency if you need XPath
support.)
- Added TemplateModelUtils.wrapAsHashUnion(ObjectWrapper, List<?>) and
wrapAsHashUnion(ObjectWrapper, Object...), which meant to be used
when you want to compose a data-model from multiple objects in a way
so that their entries (Map key-value pairs, bean properties, etc.)
appear together on the top level of the data-model.
But, if no family or workplace crisis pops up, in December I will have
time and energy to put in things. So, what to expect... and please add
your own items if you want to:
- ?truncate built-in, as was requested/implemented-by-user a *lot*,
and I have already started implementing it. Now I regret it, as it
turned out to be much more time consuming than expected... you will
see why, anyway, at this point I won't turn back.
- ?title_case: Yeah, not a prio (though we have Jira issue for
it), but it's similar to ?truncate in that it's also a built-in with
configurable algorithm (as there's no right/best implementation).
- ?map(lambda)/?filter(lambda)/?contains(lambda). So, Christoph, please
keep me updated how it goes, or if you need any help, or if you pass
it to me.
- Support "c" as boolean_format setting value, with which ${aBoolean}
prints "true" or "false". Why? "true,false" boolean_format doesn't
work for ${aBoolean}, as it's a deprecated default value, so FM will
require you to write something like ${aBoolean?string("Y,N")} or
${aBoolean?c}. Lot of users hate this, and I can fix it easily. Then
we can recommend using "c" in the error message, with the disclaimer
about why it's often a bad practice, and everyone is happy.
- someValue?c to work for string-s and date/time/datetime. Currently
it only works for numbers and boolean. For string it would just
return the string as is. For date/time/datetime... well, I could
just print the common ISO representation (like
2015-08-12T234505+0200), which is kind of useless as almost no
language understands that syntax... but the point is that
${canBeOfManyTypes?c} won't fail where ${canBeOfManyTypes} doesn't,
and I saw people sometimes want that guarantee, for debugging at
least. Actually, the ?c format of date/time/dateTime could be
configurable, now, or in a later version.
- Some random quick error message and Manual improvements... low
hanging fruits, that I saw can spare time for the users.
Yeah, quite meh so far, except
?map(lambda)/?filter(lambda)/?contains(lambda). But it's certainly
better to push this out as quickly as possible in a release, and then
go down the rabbit hole with something deeper. Digging towards
"multiple bodies"/"named bodies" for example. Or, a better white space
handling mode (aiming for source code generation, and white-space
sensitive stuff like plain text generation). Both is interesting and
can be challenging to do well. Will see...
(All of these also has to be forward ported into 3.0, which should
proceed as well. It's expensive to do everything twice, so, 3.0 should
receive more love.)
--
Thanks,
Daniel Dekany
