Extending my earlier post on standard JavaScript ${template strings}
on Marketo LPs, here’s how to use near-standard {{ variable }}
syntax.
Say you want to use AngularJS to create highly dynamic LPs, or even single-page apps, hosted on Marketo. (May not be a common ask, but it is technically feasible!)
You might declare a little ng-app
like this:
<div ng-app="">
<p>First Name: <input type="text" ng-model="firstName" /></p>
<p>Last Name: <input type="text" ng-model="lastName" /></p>
<h1>Hello {{ firstName }} {{ lastName }}!</h1>
</div>
Problem is, you won’t be able to approve the LP:

The popup doesn’t provide details, but the root cause is the super common {{ }}
delimiters, which Marketo reserves for internal use: that’s how we deploy {{lead.tokens}}
, {{my.tokens}}
, and so on! Yet you aren’t using a valid dot.ted
variable name inside them, so it’s a syntax error.
Seeing the error is good actually, since if you were using a dot.ted
name, Marketo would either (a) output nothing if the token didn’t exist internally or (b) output the internal token value if it happens to exist. Both would be confusing!
One solution is to change the delimiters (what Angular calls the interpolate provider) to something non-conflicting like [! !]
. The drawback is the final template looks different from all your other templates, and it’s also not as easy to search+replace because of possible delimiter collisions.[1]
A more elegant solution is to skip Marketo’s internal token substitution process. Do that by creating a {{my.token}}
for the opening curly braces (you don’t need one for the closing braces):

Search+replace the literal {{
with {{my.open-curlies}}
everywhere:
<div ng-app="">
<p>First Name: <input type="text" ng-model="firstName" /></p>
<p>Last Name: <input type="text" ng-model="lastName" /></p>
<h1>Hello {{my.open-curlies}} firstName }} {{my.open-curlies}} lastName }}!</h1>
</div>
Now Marketo won’t take ownership of the variable, so the {{
passes through to the browser where Angular takes over:

Notes
[1] e.g. if a template already contained the literal string [It’s time for fall!]
it’ll be erroneously included in a switch back to }}
in the future, unless you tune your search+replace regex ruthlessly.