freemarker-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Woonsan Ko <woon...@apache.org>
Subject Re: Alternative to ${exp}
Date Sun, 25 Mar 2018 14:45:05 GMT
On Sat, Mar 24, 2018 at 1:30 PM, Daniel Dekany <ddekany@apache.org> wrote:
> Saturday, March 24, 2018, 4:33:01 PM, Woonsan Ko wrote:
>
>> Hi folks,
>>
>> I'd like to bring this topic again to our attention.
>> It started totally my own mistake by being confused "Square bracket
>> tag syntax" (since 2.3.4) with the new "Square bracket interpolation
>> syntax" (since 2.3.28). [1]
>> Here's my example in another thread [2]:
>>
>> 1: [#ftl output_format="HTML"]
>> 2: [#assign a=[1,2,3]]
>> 3: [="Hello"]
>>
>> #1 and #2 work as they are using the "Square bracket tag syntax", but
>> #3 doesn't by default (unless you change the configuration to use
>> "Square bracket interpolation" option).
>> So, it should have been like the following for intention:
>>
>> 1: [#ftl output_format="HTML"]
>> 2: [#assign a=[1,2,3]]
>> 3: ${"Hello"}
>>
>> Now, I'm wondering if this kind of confusion could happen more to other people.
>> When they use square bracket tag syntax, they might be easily doing
>> the same thing for the interpolation like the first example.
>>
>> One possible solution could be to use mustache as the default
>> alternative for interpolation like this:
>>
>> 1: [#ftl output_format="HTML"]
>> 2: [#assign a=[1,2,3]]
>> 3: {{"Hello"}}
>>
>> As interpolation's alternative syntax is to use mustache, it might be
>> less confusing by not using the same syntax for both tags and
>> interpolation.
>> My old reason why avoiding mustache was, Javascript framework could
>> use both '${something}' [3] and '{{something}}' together. But also if
>> someones adopts mustache style JS frameworks, they might not use the
>> technique like [3]. Not sure though...
>
> After re-reading and re-thinking the thread, I'm back to the opinion
> that fighting the confusion arousing from the mere coincidence that
> both things are "square bracket" is the better compromise:
>
> - While using {{...}} in output is not very frequent, when it's used
>   in the output, there's a quite real chance that the output also uses
>   ${...}. A lot of languages and formats use ${...}, now including the
>   omnipresent JavaScript, and so ${...} will become more frequent in
>   web pages in the future. So, if you generate Angular pages for
>   example, it's quite possible that they use both... and then what
>   will you do?
Good point!

>
> - Using square bracket tag syntax together with square bracket
>   interpolation syntax makes template-templates (a template of a
>   template, be it FreeMarker template, JSP, etc.) easy to read, as
>   your visual cortex can just hunt for the [...]-s. It matters because
>   template-templates tend to be already messy, I guess.
>
> BTW, I have discovered a slight drawback of [=...] while using it.
> Instead of ${x} you write [=x], fine. But what do you write instead of
> ${x + 1}? The logical one is [=x + 1], but its spacing is ugly, so I
> think it's going to be [= x + 1]. One more space. Yeah, quite a nick
> picking, but just so you know about it...
Or [=(x + 1)] just for clarity?

>
>> Another possible option could be to allow to change the interpolation
>> syntax to square bracket automatically as well if the first [#ftl ...]
>> is used like the tag syntax's automatic switching per template.
>> But I'm not sure what the implication is behind about this.
>
> Templates that did work earlier won't, which is a pretty concrete
> implication. (: I wish we only had <#>+${} and [#]+[=] from the
> beginning, but now we can't do that. Not in FM2 at least. Maybe we
> should do that in FM3. Actually, yeah, it would be much easier if one
> can just chose a "template syntax", not a "tag syntax" and an
> "interpolation syntax".
Right. We cannot do that in FM2.
I prefer having fewer/simpler options in FM3, so it sounds great to
have only "template syntax" for both in FM3.

>
>> What do you think? Would my confusion be ignorable or do we need to
>> think about the alternative interpolation syntax again?
>
> It's not ignorable, but there are multiple ways of countering this. My
> grand plan (: is that some people will do that oversight you did, but
> they will realize pretty quickly that something is wrong (it's not the
> kind of problem that can remain hidden), and then they will ask
> Google, and hopefully will not be able to avoid the "notices" I stick
> every place where we are talking about square brackets. How about
> that?
That sounds like a grand plan! Let's keep the square bracket
interpolation syntax as-is and stick into everywhere! Sounds like a
non-harmful, potentially viral "square" in the squares! ;-)

Cheers,

Woonsan

>
>> Kind regards,
>>
>> Woonsan
>>
>> [1]
>> https://freemarker.apache.org/builds/fm2.3.28/dgui_misc_alternativesyntax.html
>> [2]
>> https://lists.apache.org/thread.html/2372e673c5b8bd91150f7dd43319786dda8af38acdef87cd37f09ead@%3Cdev.freemarker.apache.org%3E
>> [3] https://en.wikipedia.org/wiki/String_interpolation#JavaScript
>>
>> On Fri, Dec 15, 2017 at 5:28 AM, Daniel Dekany <ddekany@apache.org> wrote:
>>> OK, so I would go for [=exp] (see the reason told in this thread). How
>>> acceptable is that guys?
>>>
>>>
>>> Tuesday, December 5, 2017, 11:56:59 AM, Woonsan Ko wrote:
>>>
>>>> On Mon, Dec 4, 2017 at 10:28 AM, Daniel Dekany <ddekany@apache.org>
wrote:
>>>>> Monday, December 4, 2017, 10:21:48 AM, Taher Alkhateeb wrote:
>>>>>
>>>>>> uh-huh, but I suspect maybe more collisions or need to escape
>>>>>> character in something like [this] or <this> than {{this}}.
Anyway,
>>>>>> nothing critical IMO, only thinking out loud.
>>>>>
>>>>> But they were [=this] and <=this>, so the sequences that will clash
>>>>> are "[=" and "<=", which are quite rare. Oh wait... "<=" is not
rare
>>>>> at all: "if (x <= y)". But "[=" still is. OK, so I guess at this point
>>>>> the two competitors left are {{exp}} and [=exp] (regardless of tag
>>>>> syntax).
>>>>
>>>> +1.00 on [=exp].
>>>> +0.49 on {{exp}}.
>>>>
>>>> :-D
>>>>
>>>> Many languages or templates allows ${exp}, including JavaScript. [1]
>>>> And, mustache is supported in many languages or templates, too. [2]
>>>> Therefore, I think there are more chances using both ${exp} and
>>>> {{exp}} in output we want to generate in the future.
>>>> The mustache style looks charming at the moment, but I wonder how its
>>>> charming can help for the original intention (to avoid any possible
>>>> collision in the output we want to generate by an alternative as much
>>>> as we can).
>>>>
>>>> Regards,
>>>>
>>>> Woonsan
>>>>
>>>> [1] https://en.wikipedia.org/wiki/String_interpolation
>>>> [2] https://mustache.github.io/
>>>>
>>>>>
>>>>>> On Mon, Dec 4, 2017 at 12:00 PM, Daniel Dekany <ddekany@apache.org>
wrote:
>>>>>>> Monday, December 4, 2017, 9:17:34 AM, Taher Alkhateeb wrote:
>>>>>>>
>>>>>>>> So maybe a safe bet (and a familiar one) is the mustache
syntax.
>>>>>>>>
>>>>>>>> In addition to avoiding clashes it might help with a multi-chained
>>>>>>>> template. For example, we use FreeMarker extensively in Apache
OFBiz
>>>>>>>> to generate many documents including XML. Now our XML documents
might
>>>>>>>> contain some ${variable} that needs to be interpreted in
the XML
>>>>>>>> parser, not the freemarker parser (without having to escape
characters
>>>>>>>> everywhere)
>>>>>>>
>>>>>>> Though that also works with all the other proposal syntaxes as
well.
>>>>>>>
>>>>>>>> On Mon, Dec 4, 2017 at 8:50 AM, Jacques Le Roux
>>>>>>>> <jacques.le.roux@les7arts.com> wrote:
>>>>>>>>> Le 03/12/2017 à 22:06, Woonsan Ko a écrit :
>>>>>>>>>>
>>>>>>>>>> It is also most productive as no shift key is required.
>>>>>>>>>
>>>>>>>>> Depends on keyboard, for French keyboard type (azerty)
you need to use Alt
>>>>>>>>> key ;)
>>>>>>>>> Same for {{...}} anyway
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Thanks,
>>>>>>>  Daniel Dekany
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Thanks,
>>>>>  Daniel Dekany
>>>>>
>>>>
>>>
>>> --
>>> Thanks,
>>>  Daniel Dekany
>>>
>>
>
> --
> Thanks,
>  Daniel Dekany
>

Mime
View raw message