Sounds good. Looks like lots of historical quirks are removed, which is
probably. Didn't know about a lot of the things you mentioned :) We will
see in practise how this will work out I guess.
2017-07-02 1:13 GMT+02:00 Daniel Dekany <ddek...@apache.org>:
> So this is some easy to understand stuff, compared to the totally
> unpopular "[FM3] Call syntax, positional and named parameters" thread
> at least (and silence is approval, for the sake of progress).
>
> Note that all of these changes can be done automatically with the
> FM2-to-FM3 converter (which is work in progress).
>
> Note that anything between ` characters is code quotation, and the
> ` character itself is not part of the proposed syntax.
>
> So, the proposed changes:
>
> - Switch to camel case everywhere. This was already discussed months
> ago, I'm just saying it again. Other than that convention has become
> overwhelmingly popular in the Web and Java world, one reasons is
> that the Java API-s you call from the template uses that convention
> anyway. Also, remove the namingConvention setting. If someone needs
> a different convention (snake_case, typically), they should use the
> planned custom dialect feature. It's cleaner and more powerful that
> way, for example, you could even use non-English names.
>
> - Remove the long deprecated #{}.
>
> - Remove `=` as an alias to `==`. This removes ambiguities caused by
> that passing parameters by name and assignment also uses `=` with a
> different meaning.
>
> - Remove `&` and `|`, as they are just aliases to `&&` and `||`. This
> will also free up these symbols for future usages.
>
> - Add `and` and `or` as keywords. `and` is useful when you can't use
> `&&` because it's not well formed XML/HTML (which matters as some
> real-world applications impose such strange restrictions on
> templates... it's totally weird, but that's how it is). `or` is only
> for the sake of consistency. FM2 `\and`, `&&` would be
> removed (which is kind of funny, as they are added in 2.3.27, which
> is still under development).
>
> - Regarding the aliases of the `<`, `<=`, `>`, `>=` operators:
> - Replace `gte` and `lte` with `ge` and `le`, to be more similar to
> XSLT and XPath.
> - Remove `\gt`, `\lt`, `\gte`, `\lte`. They are deprecated for a long
> time.
> - Remove support for `>`, `<`, `>=`, `<=`. Some may
> point out that these were practical when you enter tags into WYSIWYG
> editors (i.e., your tags get mangled by unwanted escaping).
> Problem is, it has never worked 100% correctly for those
> applications, as other characters may be escaped there as well,
> such as an `&` in a string literal, or even quotation marks. So to
> support that use case, we will need to add a feature that properly
> un-escapes everything (even tag delimiters!), instead of adding
> hacks to the expression syntax that only work around the problem
> sometimes.
>
> - Fix `exp!exp` precedence. In FM2 `a + b!c + d` means `a + b!(c + d)`,
> which is just wrong. It should mean `a + (b!c) + d`, but it can't be
> fixed there as it's not a backward compatible change.
>
> - Less liberal comment syntax inside expression.
> In FM2, inside expressions (as opposed to between tags), you can use
> all of these as comments, regardless of the tag syntax: `<#-- -->`,
> `[#-- --]`, and surprisingly even `<!-- -->`. In FM3, you could only
> use either `<#-- -->` or `[#-- --]`, whichever matches the tag
> syntax of the template.
>
> - Interpolations shouldn't be string-escaped anymore in string
> literals. In FM2, when you have an interpolation inside a string
> literal, its content has to be properly backslash escaped, just like
> normal
> characters in the string, for example:
> `${"A backslash: \\. Another backslash: ${'\\\\'}"}`
> or `${"Foo ${\"Bar\"}"}`
> This is not very user friendly IMO, and also complicates parsing
> considerably (bad for us, bad for 3rd party tooling). I have checked,
> and nor Groovy nor Kotlin does this. So in FM3 you had to write
> this:
> `${"A backslash: \\. Another backslash: ${'\\'}"}`
> or `${"Foo ${"Bar"}"}`
>
> - SQL-like quotation character escaping in raw strings literal. Raw string
> literals are like r"\d+" or r'\d+'; both literally means \d+. You
> can include any characters without escaping, in fact there's no
> escaping inside raw string literals. Problem is, then you can't
> include the literal quotation character in the content, as there's
> no way escaping it. I propose we allow that like this:
> r'It''s an example.' or r"This is ""quoted""."
>
> --
> Thanks,
> Daniel Dekany
>
>
--
Christoph Rüger, Geschäftsführer
Synesty <https://synesty.com/> - Anbinden und Automatisieren ohne
Programmieren - Automatisierung, Schnittstellen, Datenfeeds
Xing: https://www.xing.com/profile/Christoph_Rueger2
LinkedIn: http://www.linkedin.com/pub/christoph-rueger/a/685/198
--
Synesty GmbH
Moritz-von-Rohr-Str. 1a
07745 Jena
Tel.: +49 3641 559649
Fax.: +49 3641 5596499
Internet: http://synesty.com
Geschäftsführer: Christoph Rüger
Unternehmenssitz: Jena
Handelsregister B beim Amtsgericht: Jena
Handelsregister-Nummer: HRB 508766
Ust-IdNr.: DE287564982
