Monthly Archives: October 2013

Dust is eloquent

By

“Dust is eloquent”   – Benedict Cumberbatch in “Sherlock”
eloquent – Clearly showing feeling or meaning – Merriam Webster dictionary

In the inaugural post of the PayPal Engineering Blog, we introduced Dust as the UI templating solution for all of PayPal’s development environments (Node.js, Java, and c++).  That post really didn’t say a lot about the details of Dust. Today, let’s “be the UI engineer” and see how Dust lets us express ourselves in a natural way to convey the experience we want for the user. This will teach you a bit about Dust and, hopefully, encourage you to learn more.

UI engineers work in three separate technologies: HTML, JavaScript and CSS. Taken together, these three deliver the amazing range of experiences you see using a modern web browser. From the UI engineer’s perspective, HTML is the natural mode of expression. However, without dynamic data, all you have is a static page so some compromise must exist to weave dynamic material into an HTML page. Some solutions for incorporating data, like JSP, tend to be to “in your face” and obscure the HTML the developer is working on. A minimal footprint on the basic page that leaves it still viewable in editing tools is a plus. Dust strives to remain in the background, as much as possible.

Dust deals with just two inputs, a template (aka HTML page with some dust tags)  and dynamic data. The data part is constructed by the business logic and contains dynamic information for use with the template.  The data is in JSON, a natural format since Dust is a JavaScript-based template language. This choice turns out to be a good one for other reasons. The back-end logic that generates the JSON data, can equally well supply the data to a smart phone application to render in native mode, or it can supply it to a web client Ajax request to render to HTML local to the browser.

The developer adds Dust tags to the HTML defining how to incorporate values from the data. In many ways, Dust tags are akin to HTML tags. Instead of < and >, Dust tags are enclosed with { and }. Where HTML uses </name> for a closing tag, Dust uses {/name}.

Rather than a lengthy exposition, let’s use an example to see how a Dust template and associated data are processed. This example deals with presenting address information for a user.

Fill In the Blanks Example

Address Template:
<div>>{street}</div>
<div>{city}, {state}</div>

Data in JSON format:
{
"street": "234 First Avenue",
"city": "Anytown",
"state"": "CA"
}

The Dust template processor starts copying everything from the template to the output until it encounters something wrapped in braces; in this case that would be the string {street}. This is the simplest dust tag and is equivalent to a “fill in the blank” process.  Dust looks for “street” in the data and outputs the value in place of the {street} token. Applying the process to the entire template, the output will be:

<div>234 First Avenue</div><div>Anytown, CA</div>

Great, now we can write form letters. What happens if {name} cannot be found in the data? Simple, nothing is output and processing moves on. So what if the address data is part of a more complex user object like the following:

{
 "user": {
     "name": "Mary Smith",
     "address": {
         "street": "234 First Avenue",
         "city": "Anytown",
         "state": "CA"
     },
     "phone": "(650) 555-1212"
  }
}

In order to reference the street field, we need to use what Dust calls a path.

{user.address.street}

This will output the street value. Since this is the same general notation that a developer would use in JavaScript it feels natural. The previous address template looks like this when paths are used:

Address Template:
<div>{user.address.street}</div>
<div>{user.address.city}, {user.address.state}</div>

However, a UI engineer’s job is a lot more complicated than just filling in blanks in an HTML page. There are problems like generating a list of all accounts, showing alternate text when data is missing, and more. In the future posts, I’ll delve further into what dust offers the developer. Future topics will include

  • Handling lists of data
  • Logic-less templating. How viable is it?
  • Reuse with dust for the UI engineer
  • Security considerations for the UI engineer
  • Dealing with internationalized content

In the next post, I will cover “Handling lists of data”