[FreeMarker-user] Using dashes and colons in directive parameter names

[Eirik Lygre]

We have a user defined directive which can be called from freemarker as
shown below The directive will use some well-defined parameters (here
"name"), but will output all other directives directly, so that you can do
for example this:

[@form.input name="task.dateFormat" /]
[@form.input name="task.dateFormat" class="dateInput important required"
style="display:block" accesskey="D" /]

Now, we have seen the requirement to generate attributes with special
characters, such as with xml namespaces or html 5 custom data attributes.
For example:

[@form.input name="task.dateFormat" xml:lang="no"
data-format="dd.mm.yyyy" /]

This fails during parse. I tried the obvious, quoting the parameter names,
but that did not work. (Now, using special names would probably not work
for macros, but our directives are implemented in java, and the parameters
are passed as a straight array, with no syntax constraints).

-> Is it possible (today) to use parameter names with special characters?
-> How about tomorrow-ish :-)

[Daniel Dekany]

Post by Eirik Lygre
We have a user defined directive which can be called from
freemarker as shown below The directive will use some well-defined
parameters (here "name"), but will output all other directives
required" style="display:block" accesskey="D" /]
Now, we have seen the requirement to generate attributes with
This fails during parse. I tried the obvious, quoting the parameter
names, but that did not work. (Now, using special names would
probably not work for macros, but our directives are implemented in
java, and the parameters are passed as a straight array, with no syntax constraints).

->> Is it possible (today) to use parameter names with special characters?

No. You will have to go with "data_format" and if necessary, translate
it to "date-format" later.

->> How about tomorrow-ish

The case of "-" is a well-known problem. So it's admitted that this
should be improved. When will that happen... I can't tell.

BTW, I don't think it can be fixed without breaking
backward-compatibility. There's a historical mistake that the ==
operator can be written as =. But when something looks like a
parameter name, the parsers sees = as a named parameter assignment
instead. But that doesn't stand for [@foo "data-format"="bar" /], as
it's currently interpreted as [@foo "data-format" == "bar" /] (a
single position parameter with boolean value). Changing this wouldn't
be backward-compatible.