Late december 2.3.29 release features

[Daniel Dekany <dd...@apache.org>]

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

Re: Late december 2.3.29 release features

[Daniel Dekany <dd...@apache.org>]

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