Skip navigation
All Places > Products > Blog > 2018 > March
2018

Boolean type fields enjoy a strange place in Marketo's Velocity implementation.

On the Marketo UI side and via most Marketo APIs, Booleans hold consistent true/false values (presumably using SQL bit type fields under the hood).

But in Velocity, as I've explored before, a Boolean field is presented as one of two Strings:

  • "1" for Boolean true
  • "" (empty string) for Boolean false

That conversion is actually really confusing.

See, Velocity inherits a lot of things (variable handling things) from Java.

In Java, a non-null String object, on its own, is always evaluated as Boolean true. Regardless of whether it has any characters in it (that is, regardless of whether it's empty).

So if you do:

#if( $lead.someBooleanField )
Field is true
#else
Field is false
#end

You will always get “Field is true” even if you've unchecked the corresponding checkbox in the Marketo UI.

If Marketo Booleans were Velocity/Java Booleans, on the other hand, this would've worked fine. But alas.

So the question is what to do with these sort-of-Boolean-like-Strings (whose meaning we understand, but the VTL language doesn't). What do we convert them to to make them more usable?

You can do a step-by-step conversion to Boolean by doing a String comparison:

#if(  $lead.someBooleanField.equals("1") )
#set( $lead.someBooleanField == true )
#else
#set( $lead.someBooleanField == false )
#end

After that conversion, #if($field) will work as expected.

But I've been thinking lately that maybe converting those Strings to Numbers — 0for false and 1 for true, as the standard goes — gives us more juice within Velocity than if we were to go with true Booleans.

 

 

Read the full post on TEKNKL :: Blog →

Summit is just a little over a month away (April 29th-May 2nd) and you don’t want to miss out! Make sure you have your pass so you can join us in San Francisco to learn from marketers like you who share similar goals and have fearlessly faced similar challenges:

  • Sendgrid’s Jacob Hansen sharing best practices for maximizing your email deliverability
  • SiriusDecision’s John Donlon on proven steps to a successful ABM implementation
  • Uber’s Wyatt Bales on building a next-gen Marketing Operations organization
  • Hands-on workshops on A/B testing and Advanced Reporting with Digital Pi’s Jessica Kao
  • CenturyLink’s Scott Berns on how they keep their robust database healthy
  • Meet ups for financial services, healthcare, manufacturing, higher ed marketers like you

 

This year we’ve doubled the amount of technical Marketo content! Check it out.

 

Who's going to be there? 

    Velocity is the only language where Brevity for Brevity's Sake is OK.

    In other languages, reducing total lines of code (LOC) with show-offy shortcuts just means your code will make no sense (to you or anyone else) after a few months away.

    But in Velocity, the shortest possible implementation is a smart move, since:

    • VTL is verbose (only one major operation permitted per line, temp variables required even for void methods)
    • it offers limited reusability (especially Marketo's flavor of Velocity, where #macro and reused $references don't work consistently)
    • it's completely whitespace-preserving (indenting would help readability, but messes up output — so the fewer lines, the less to mess up)
    • the more lines of code in your template, the more distraction from the “meat,” which is the output

    Imagine you had a few Lead fields using the JETDS naming system: installationEnvironment, typeOfEquipment, and purpose.

    There are 10-20 options for each of these fields, so the number of total combinations is huge. Even if you're only interested in a subset, the conditions get loooooong...

 

#* 
I'm being generous with whitespace here, 
but it's *still* hard to read/maintain! 
VTL is whitespace-preserving, so indents are true spaces.
*#
#if( $lead.installationEnvironment == "amphibious" )
 #if( $lead.typeOfEquipment == "radar" )
   #if( $lead.purpose == "receiving" )
   do something...
   #elseif( $lead.purpose == "detecting" )
   do something else...
   #elseif( $lead.purpose == "navigation-aid" )
   do something else entirely...
   #end
 #elseif ( $lead.typeOfEquipment == "sonar" )
   #if( $lead.purpose == "receiving" )
   do yet another thing...
   #elseif( $lead.purpose == "detecting" )
   do still another thing...
   #elseif( $lead.purpose == "navigation-aid" )
   ...
   #end
 #end
#elseif( $lead.installationEnvironment == "ground-mobile" )
 #if( $lead.typeOfEquipment == "radar" )
   #if( $lead.purpose == "receiving" )
   ...
   #elseif( $lead.purpose == "detecting" )
   ...
   #elseif( $lead.purpose == "navigation-aid" )
   ...
   #end
 #end
#end
## etc., etc.

 

Read the full post on TEKNKL :: Blog →

Y'all have seen this type of double-confirmation popup, I'm sure:

ss

It's helpful if you want to give end users a little additional nudge, for example to use their legal name, a working email address, and so on — stuff that you can't force them to do but maybe can guilt them into.

No one but me would claim it's “easy” to add this functionality to a Marketo form. It only took an hour to whip it up, but as you know, I waste spend more time in Forms 2.0 API-land than anybody else. I've provided a big leg up: a working CodePen you can spin off for your own site.

Most of the heavy lifting is done in CSS: overlaying the background, positioning the popup bar, changing the color of the Cancel/Go Back button. Aside from managing the visibility of the bar (display: block or display: none) there's not a huge amount happening in JavaScript.

 

 

Read the full post on TEKNKL :: Blog →

Filter Blog

By date: By tag: