TPL Parse Error when calling more than one function on a value

[Sottilde]

I have an interesting situation where, for visual reasons, I want to run two different functions on a date to extract different parts of it and style them differently. My code is much like the following:

<div>
  <span class="number">
    {deadline:getTimeSpanNumber()}
  </span> 
  <span class="label">
    {deadline:getTimeSpanLabel()}
  </span>
</div>

I have extended Ext.util.Format to add these functions.

The above code throws a parse error in the latest build of Architect.

The error reads:

Invalid tpl: Parse error

... (snip) copy of TPL above ...

Source Class: xds.component.config.Template
Source Method: normalizeValue

However, the following equivalent code does not throw a parse error and works as expected:

<div>
  <span class="number">
    {deadline:getTimeSpanNumber()}
  </span> 
  <span class="label">
    {[Ext.util.Format.getTimeSpanLabel(values.fundingDeadline)]}
  </span>
</div>

[Sottilde]

This issue is getting to be more and more annoying and is breaking major functionality in my app, as well as causing me to lose hair.

Using multiple format calls in a single TPL always results in parse errors. I cannot do something like:

Money: {price:usMoney()} Money2: {fee.usMoney()}

I must instead do:

Money: {price.usMoney()} Money2: {[Ext.util.Format.usMoney(values.price)]}

Any other calls to usMoney() in the entire TPL, if not wrapped in {[]}, causes a parse error in Architect.

[aconran]

Scott - we're looking into this one.

[jjohnston]

Is your project an Ext JS project or a Sencha Touch project?

[Sottilde]

ExtJS.

[jjohnston]

Interesting, it appears that Ext JS 4.0.7's own XTemplate parser rejects these examples... for instance I created a blank Ext JS app and ran the following in onReady:

Ext.create('Ext.XTemplate', 'Money: {price:usMoney()} Money2: {fee.usMoney()}')

This results in the same parsing error that you see within Architect, which makes sense because we use Ext's own XTemplate implementation to do the parsing for validation.

This definitely seems like a bug, but it seems like a bug in the Ext JS framework itself, and that Architect is doing the right thing in warning you about it up front.

[jjohnston]

Reading it again more carefully I noticed there was a syntax error in that particular example, should have been fee:usMoney() rather than fee.usMoney().

However even after fixing that the problem still persists. I went to the API docs and noticed that in the example code in the Template class, they do not include the parens after the formatting method if it does not have arguments, so:

'Money: {price:usMoney} Money2: {fee:usMoney}'

This does, in fact, work in both a standalone Ext app and within Architect. Perhaps this is just a quirk of the template syntax where it does not like empty open-close parens?

[Sottilde]

Reading it again more carefully I noticed there was a syntax error in that particular example, should have been fee:usMoney() rather than fee.usMoney().

However even after fixing that the problem still persists. I went to the API docs and noticed that in the example code in the Template class, they do not include the parens after the formatting method if it does not have arguments, so:

'Money: {price:usMoney} Money2: {fee:usMoney}'

This does, in fact, work in both a standalone Ext app and within Architect. Perhaps this is just a quirk of the template syntax where it does not like empty open-close parens?

Good catch! It seems that in ExtJS 4.1 the template I provided does in fact work correctly in a console test, even with the empty parens.

Removing the empty parens works for me. It seems that the first empty parens throws something off in the parsing that makes any second call with empty parens fail.

I suppose this bug will resolve itself once Architect upgrades to 4.1.