Using Velocity macros in email templates

[WolframLotz]

Hi everyone, 

I like to use a velocity macro within an guided email template. I alreay found out that it is possible to add the macro on template level within the body and that it is not possible to change (or add) the macro in the code editor of the specific email asset. 

Is anybody of you familar with using VTL macros in email templates? 
Ar there things to consider? Gos, no-goes or best practices? 

Or are there any restrictions that you would absolutely advise to not use macros in templates? 

[SanfordWhiteman]

---

I like to use a velocity macro within an guided email template. I alreay found out that it is possible to add the macro on template level within the body and that it is not possible to change (or add) the macro in the code editor of the specific email asset. 

Is anybody of you familar with using VTL macros in email templates? 
Ar there things to consider? Gos, no-goes or best practices? 

Or are there any restrictions that you would absolutely advise to not use macros in templates? 

---

Don’t know what you mean here. Velocimacros are fully supported in {{my.tokens}} — I have utility macros running everywhere.

Perhaps what’s confusing you is macro definitions are cached until the JVM restarts, which you should interpret as “forever” when changing macro code, always creating a new #macro_v2 instead of changing #macro_v1.*

As I mentioned in your other related thread, there’s almost zero justification for putting Velocity code directly in the email body, whether it be in the email template or in an individual email asset. It carries an immense risk of regression, which I’ve seen several times. (Regressions affecting VTL in {{my.tokens}} are worry enough!)

*since it’s not actually forever, there’s no guarantee that your macro cannot be redefined by any other Velocity code, which is why you should collaborate with people you trust

[WolframLotz]

Hi @SanfordWhiteman 
thanks. It's pretty easy. The code handles URLs which are requested to be handled by link tracking. 
If I bring the code into a my.token it will not be handled from link tracking. 

AND: the template will fail in a workspace the token is missing or changed in an inappropriate way. 

From administration side we have to ensure that all templates will work correctly independend from what a non-technical affine author will change on his/her program. 

So we have to ensure that the script is part of the template rather than beeing part of a my.token. 

[SanfordWhiteman]

---

thanks. It's pretty easy. The code handles URLs which are requested to be handled by link tracking. 
If I bring the code into a my.token it will not be handled from link tracking. 

---

URLs that are output from Velocity {{my.tokens}} can be tracked. What do you mean?

---

From administration side we have to ensure that all templates will work correctly independend from what a non-technical affine author will change on his/her program. 

So we have to ensure that the script is part of the template rather than beeing part of a my.token. 

---

A template that relies on unsupported features is not a template that will continue to work correctly. It’s the complete opposite of high-trust — it’s a ticking time bomb waiting to suddenly and permanently stop working!

Look, as likely the premier user of Velocity across the whole Marketo community, I would only deploy such a thing if (a) I won’t be blamed when (not if) it stops working and (b) I’ll have unlimited time to fix it.

Seems to me that if the only reason you’re doing this is because you have employees who insist on altering Velocity code that they don’t understand, their continued employment could be called into question.