Can't name a template parameter `one`

[olaf-k]

I've come across a weird behavior whenever I use one as the name of a sub-template parameter.

This is the working code:

{export template test()}
    <#hello pone="one" two="two"/>
{/template}

{template hello(pone, two)}
    this is {pone} and {two}
{/template}

Now, for the funny stuff, if you replace pone by one everywhere, the output becomes: this is [object Object] and two ...because for some reason, one's value is {two:"two"}

If you invert one and two, you'll get: this is two and ...because this time, one's value is undefined.

[ymeine]

It seems like some things I wrote for the API documentation have disappeared, that's not good... Except if something has been done in the implementation to justify that.

So what was written in my version of the documentation, is that when you use an attribute whose name begins with on, it is expected to be an attribute of type callback (like onclick and so on), hence a probable processing made by the library, resulting in this mess.

[marclaval]

I can understand that the onsomething attributes must be callback for EltNode (i.e. HTML elements), but it seems weird be the case for sub-templates or components.

[b-laporte]

Well we need a way to differentiate callback attributes from normal attributes - because the expression context is different - and today this is done through a naming convention (i.e. callback attributes must start with on). So until we find a better solution, I would stick to this convention. Btw. this also means that we should be able to write sth like this:

<template id="foo" args="msg,onclick">
  <div onclick="{onclick()}">{msg}</div>
</template>

... which doesn't work today (but this should be a separate item in the backlog) We could also dynamically check the attribute types of attributes starting with on to make sure they can be interepreted as callbacks - otherwise clear errors should be raised to help userd understand their mistakes.

[benouat]

@b-laporte correct if I am wrong, but I think that when we process the attributes at template usage, we know if:

• this is just a stupid template, in which case we should not check by now, but just when the event is occuring.
• this is a component, thus we should validate the "on" check.

[PK1A]

@benouat for the regular templates we could deffer checks to the point where the event occurs but it would be a pity since we've got all the needed info at the compile time. That is - if we've got a way of identifying event handlers we've got an AST for the expression present in this attribute and we can verify that there is only function call (or an assignment later on).