Wednesday, November 29, 2017, 12:53:11 AM, Daniel Dekany wrote:
> Tuesday, November 28, 2017, 8:43:49 PM, Denis Bredelet wrote:
>
>> Hi Daniel,
>>
>>> On 28 Nov 2017, at 15:45, Jacques Le Roux <[email protected]>
>>> wrote:
>>>
>>> Le 28/11/2017 à 16:43, Jacques Le Roux a écrit :
>>>>
>>>>
>>>> Le 28/11/2017 à 10:45, Daniel Dekany a écrit :
>>>>> This problem comes up again and again: the ${exp} syntax clashes with
>>>>> the syntax of the thing the user wants to generate. So I believe we
>>>>> need a Configuration option to address this. Something like
>>>>> cfg.setInterpolationSyntax(FOO_INTERPOLATION_SYNTAX), and also
>>>>> <#ftl interpolationSyntax="foo">.
>>>>>
>>>>> Like any syntax option, this is potentially confusing for users and
>>>>> problem for tools, but I don't think there's a way around this. Users
>>>>> have to deal with those clashing ${}-s somehow, and certainly an
>>>>> in-house hack will be worse and even more confusing. (Surely they can
>>>>> write ${'$'}{foo} or use #noparse, but if you need a lot of those,
>>>>> then it's obviously not an acceptable workaround.)
>>>>>
>>>>> So, what the syntax would be? Some of my ideas:
>>>>>
>>>>> - {{exp}} is probably the nicest. For the same reason it potentially
>>>>> clashes with something yet again, though I guess it's unlikely
>>>>> enough that neither ${exp} nor {{exp}} works for you.
>>
>> Mustache style, in fact I would choose that other the default :-)
>>
>>>>> - @{exp}. It's similar to ${exp}, which I think is an advantage.
>>>>> There's however a very small but still real chance that for someone
>>>>> both ${} and @{} clashes with what they want to generate, because
>>>>> using <someChar>{name} is somewhat popular.
>>>>>
>>>>> - #{exp}. That looks like the natural choice as we use # in tags as
>>>>> well (also @, though). The reason I don't like it is that
>>>>> we already have #{exp} in the standard syntax, but it's deprecated.
>>>>> That's not a problem technically, as you can say that if you select
>>>>> the #{} syntax, then it's not deprecated, and ${} will be treated
>>>>> as static text. But now if someone sees #{exp}, they can't tell if
>>>>> the template uses a deprecated syntax, or it uses the alternative
>>>>> interpolation syntax. Also it's perhaps more likely that for someone
>>>>> both ${} and #{} clashes (e.g. in the case you generate JSF JSP-s),
>>>>> than that that both ${} and @{} clashes.
>>>>>
>>>>> - <=exp> and [=exp] depending on if you are using square- or
>>>>> angle-bracket tag syntax. Look somewhat exotic... which also means
>>>>> that hopefully it won't clash with anything.
>>>>>
>>>>> There's also the idea that we just let the user specify any separator,
>>>>> like `cfg.setInterpolationStart("@{"); cfg.setInterpolationEnd("}")`.
>>
>> How about just:
>>
>> cfg.setInterpolationPrefix("@")
>>
>> If the start character is "{" then use {{ }}, else use #{ } or @{ } or
>> whatever you choose.
>
> The problem is that JavaCC doesn't really support such things. The
> syntax is static in it. But we could hardwire all the sane symbols
> into it (something like $@#%&), and then decide on runtime if we want
> to change that token (like a "@{" token) to static text.
>
> BTW, this reminds me that sometimes the problem is using "{" itself.
> Some syntaxes (like RTF and Jira/Confluence) reserve that character,
> and so no mater what character you put before it, it's still clashing.
That's not a problem though, only I was too sleepy apparently... Only
FreeMarker need to be able to identify the interpolations, then they
will be substituted anyway.
> And even {{exp}} has the same problem.
So, there's actually no problem with it (as far as the output format
doesn't use "{{" commonly).
> So it seems that we need an
> additional (or, the only alternative) syntax that doesn't use "{".
> <=...> and [=...] comes into mind (though they are a bit complicated
> as they depend on the tagSyntax as well).
>
>> — Denis.
>>
>>>>> But if all kind of random syntax is possible, it's harder for users to
>>>>> figure out what's going on (their syntax isn't mentioned in the
>>>>> Manual, and nobody on StackOverlfow recognizes it either), and it's
>>>>> more difficult to support that in tools as well. So I believe it's
>>>>> better for everyone if there's one, or maybe two standard
>>>>> alternatives. (Not to mention that I don't yet see how to implement
>>>>> such a runtime-configured syntax with the current JavaCC-based parser.
>>>>> Probably it would be a horrid hack if possible at all.)
>>>>>
>>>>> Opinions, ideas?
>>>>>
>>>>
>>>>
>>> Oops wrong button => blank message :/
>>>
>>> I also prefer {{exp}} for the simple reason that it reminds me Jira and of
>>> course also for the reasons you explained
>>>
>>> Jacques
>>>
>>
>>
>
--
Thanks,
Daniel Dekany
