Sunday, December 3, 2017, 10:06:48 PM, Woonsan Ko wrote:
> On Tue, Nov 28, 2017 at 4:45 AM, Daniel Dekany <[email protected]> wrote:
>> 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.
>>
>> - @{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.
>
> I personally prefer the style with square-bracket: [=exp], which seems
> most unique and intuitive.
You mean, even if you're using the angle bracket tag syntax (like
<#if foo>)? If somebody cares about pressing shift, I think he can use
square bracket tag syntax (like [#if something]), and so spare the
shifts needed for the tags as well. I have assumed that otherwise it
worths more that <=exp> is more consistent with the tag syntax. But
maybe it doesn't after all.
Actually, [=exp] has the slight advantage that it doesn't interfere
with the HTML/XML syntax (which FreeMarker doesn't care about, but
some tools can get confused), similarly as ${exp} didn't. As some
users mostly only use interpolations inside HTML/XML tags, I can
immagine that they aren't concerned enough about the angle brackes of
the FTL tags to switch to the less well known square bracket syntax.
Also, if the interpolation syntax doesn't depend on the tag synax
(it's always [#exp]), that might prevents some user confusion. Also it
doesn't complicate the parser that much.
> It is also most productive as no shift key is required.
> I like [=exp] better than <=exp> by the way, because the latter is
> confusing (looks like <%=exp>) and requiring shift keys.
So far we have heard 3 preferences:
- {{exp}}
- <someChar>{exp}, where <someChar> is specified in the Configuration,
so you end up with something like @{exp}, %{exp}, etc.
- [=exp], but even if the tagSyntax setting is angle-brackets (if I
understand well).
I'm torn between all three, with a slight bias towards [=exp] now.
That's probably the most practical solution, except, some users can't
stand unusually looking syntax like that.
> Regards,
>
> Woonsan
>
>>
>> There's also the idea that we just let the user specify any separator,
>> like `cfg.setInterpolationStart("@{"); cfg.setInterpolationEnd("}")`.
>> 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?
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>
--
Thanks,
Daniel Dekany
