Yeah, this did not happen... some unexpected work came up in December.
Anyway, I'm still grinding away on this veeery slowly. Given the
sluggish pace, after the lambda(ish) feature with ?filter/?map (I did
some uncommitted progress there this weekend) I think I will just
proceed with a release.
Sunday, November 18, 2018, 6:36:23 PM, Daniel Dekany wrote:
> 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
