I'm forward porting the changes from 2.3-gae into 3.0 as a form of code
self-review. Especially in case nobody else takes a look. I will try to do
that with CFormat/?c/?cn tomorrow, if my health allows it. I'm quite sick.
Not sure if I will be able to proceed next week with FREEMARKER-35.
On Tue, Dec 27, 2022 at 12:25 AM Daniel Dekany <ddek...@apache.org> wrote:
> OK, it has grown to be not that minimalistic after all. Nowadays I see
> people suffering with generating JSON, in particular string literals that
> can be null. With 2.3.31 (the old version) it's like this:
>
> {
> ...
> "fullName": <#if
> user.fullName??>"${user.fullName?json_string}"<#else>null</#if>
> ...
> }
>
> So I wanted to offer some new built-in for that, and it went further than
> I anticipated. Because, I realized that I can say that ?c generates
> literals in a target computer language, and therefore someString?c could
> generate a string literal in that computer language (a quoted, escaped
> thing). Currently ?c doesn't support strings, so that's backward
> compatible. So I generalized ?c a bit, which caused further changes at
> many places. Like I had to add the c_format setting to specify the target
> computer language.
>
> Then I also added a new built-in, ?cn, for "C Nullable", which will output
> a null literal if its left side operand is a null/missing value (?c just
> dies with missing value error). I know, yet another cryptic shorthand, but
> in the use cases where these are needed, you often use them a lot. Also ?c
> is already like that. So now the earlier example is reduced to this:
>
> {
> ...
> "fullName": ${user.fullName?cn}
> ...
> }
>
>
> Of course ?cn will work with numerical and boolean values as well, as it's
> the same as ?c, except when it comes to handling null/missing values. At
> places where you don't expect null/missing values, you should use ?c
> instead of ?cn.
>
> Updated change log/documentation is here:
> https://freemarker.apache.org/builds/2.3.32-preview/docs/versions_2_3_32.html
>
> Feedback is welcome!
>
> I might add a bit more, but not much more, as I should wrap up 2.3.32, and
> then go on with java.time support.
>
>
> On Fri, Dec 16, 2022 at 1:07 PM Daniel Dekany <ddek...@apache.org> wrote:
>
>> Hi,
>>
>> I'm adding some smaller changes to the 2.3-gae branch, so we can do a
>> release relatively quickly, without waiting for the ever dragging java.time
>> support. I hope it will be ready for voting in a few days, which means that
>> it can be released this year.
>>
>> Here's the change log so far... but it will grow. The changes related to
>> ?c are already quite substantial, so take a look if you can:
>>
>> https://freemarker.apache.org/builds/2.3.32-preview/docs/versions_2_3_32.html
>>
>> After the voting (in a few days if all goes well), I will continue with
>> java.time support, which will be part of the next release after this coming
>> 2.3.32 release.
>>
>>
