Mathematical operators in ACP templates?

[opentype]

Sometimes I have to use use mathematical operators within template tags in templates, e.g. {{ … > … ;}}

But this kills the HTML styling for parts of the template or even the rest of the template, making it hard to navigate the document, spot errors and it also kills the automatic code indentation. 

Is there any way around that? 

Edited January 21, 2022 by opentype

[IPCommerceFan]

What about..

{{ $gtsym = '>'; }}
{{ ... $this . html_entity_decode($gtsym) . $that ... }}

I didn't test it, so I'm not sure if that would simply lead right back where you started.  It seems plausible though.

[Hatsu]

This would lead to a syntax error in PHP as an operator itself can't be a function. Or am I wrong?

Actually, the editor would have to be modified that text between {{ }} should not be parsed for syntax highlighting.

Edited January 21, 2022 by Hatsu

[Runar]

@opentype

Are you sure your issues are caused by the mathematical operators and not by something else? In the second example in this help guide, the same operator as in your post is used, apparently without issues:

{{if count( $items ) > 0}} ... {{endif}}

It would be easier to recreate the issue if you could post a complete example of something that fails.

[opentype]

1 hour ago, Runar said:

 

Are you sure your issues are caused by the mathematical operators and not by something else?

Yes. The styling library working in the background expects HTML and treats < and > as parts of tags, even when they are part of the PHP template tags. I deliberately didn’t post a specific example, because I was hoping there could be a general solution, not just a work-around for a specific case I would post. 
Just to be clear: the code works. It’s the dynamic styling that breaks, making coding in the ACP unnecessarily difficult. 

[Runar]

1 hour ago, opentype said:

Just to be clear: the code works. It’s the dynamic styling that breaks, making coding in the ACP unnecessarily difficult. 

I first couldn’t make it break, but now I can confirm that this does indeed happen with the < operator:

This looks like a bug to me, and not something we should have to work around. The only “fix” I found was to immediately follow the < operator with a >, but that doesn’t always make sense.

[Sonya*]

On 1/21/2022 at 9:07 PM, opentype said:

because I was hoping there could be a general solution

The general solution is to stop your IDE to parse inside {{}} as @Hatsu suggested.

On 1/21/2022 at 7:40 PM, Hatsu said:

the editor would have to be modified that text between {{ }} should not be parsed for syntax highlighting.

E.g. no issue with the code when using PhpStrom:

[Runar]

58 minutes ago, Sonya* said:

The general solution is to stop your IDE to parse inside {{}} as @Hatsu suggested.

The reported problem is that this issue happens in the built-in theme editor, not in an external IDE.

[Nathan Explosion]

This should make it clear for other to understand:

Valid code (works) & syntax highlighting ok:

 

Valid code (works) & syntax highlighting no longer ok:

Combine both & syntax highlighting now ok:

 

Flip them around & syntax highlighting no longer ok:

[Runar]

6 minutes ago, Nathan Explosion said:

Combine both & syntax highlighting now ok:

I would say okay enough, as the code after the if statement is correctly highlighted but the second part of the if statement (AND $myNumber) is not.