Front-end Series 3: Templating syntax review

  1. Template syntax families
  2. Binding simple values
  3. Binding values using Scope Blocks
  4. Grammars
  5. Parsing
  6. Consistency leads to Predictability
  7. Comparison of popular templating syntaxes
    1. String Insertion
    2. Iteration
    3. If

Templating syntax (and language syntax in general) is very interesting. How a template is written somewhat informs mental-model of how it behaves, and how the data should be structured.

The following is a syntax review of common features in front-end templating systems. This is an initial pass! If you see any errors or optimizations, please correct me in the comments and I’ll quickly correct them. Also, this isn’t a review of the (sometimes very extensive) templating engines themselves — just the template syntax.

Template syntax families

At a very high-level, template syntax falls generally into two families: element-attribute renderers, and inline-token renderers.

Element-attribute style syntax binds data, logic, and state to a template by attributes on an individual node:  <element directive="property" /> . These templates are often parsed using traditional DOM parsing techniques, looking for element attributes that match a set of defined directives for that framework.

In inline-token renderers, binding is performed by code (or expressions) in-place, using special tokens to set it apart from the markup: like  {{ , <@ , or  <% . These templates are parsed using string or pattern matching techniques on the tokens, then evaluating their contents.

These are general distinctions, and some templating frameworks use both syntax styles.

Binding simple values

Inline-token style syntax really shines when binding single values to a template:

Because the templates are parsed as strings, using pattern matching regular expressions to find tokens, the binding can occur anywhere within the template, making them very powerful:

Element-attribute syntax expressions bind simple data easily, but quickly become verbose and unwieldy when replacing complex content:

 Binding values using Scope Blocks

Many templates also include some logic expressions, such as  if, foreach, and  using. Inline-token expressions can be limited when working with logic blocks — one reason is scope management. Element-attribute syntax declares expressions on the elements themselves, which have a natural scope within the DOM tree: they start, end, and have children. This makes data binding when scope is required simple:

Inline-token expressions are parsed with pattern-matching and could occur anywhere, so the parser must maintain the scope of any logic blocks used in a template. Additionally, the template syntax must contain closing tags for each opening logic block.


handlebars-grammarEach templating syntax comes with its own grammar — or structure. A study of language grammar is a post on its own (or a degree of its own!), but a brief look at grammar is useful to understand the different syntax of each templating framework.

A grammar is a logical structure that defines what is acceptable in a language. Although templating frameworks can have a grammar, they aren’t necessarily languages on their own.

Lets look at the handlebars templating framework:

A handlebars expression starts with the tokens  {{ , and contains three sections:

  • An optional additional  { token
  • An optional logic expression :  #with , #using , #if , #else , #unless
  • A variable or object

Once defined, a basic grammar can be represented as a regular expression. Regular expressions can be represented differently in different languages, but this one should be generic enough:

{{{?(#[a-z]+ )?[a-z]+.[a-z]*}?}}


  • Match the string  {{ (opening token)
  • followed by zero or one  { (unescape token)
  • followed by zero or one  #[a-z]  strings (logic directives)
  • followed by an  [a-z]  string (variable or expression)
  • Followed by zero or more  .[a-z] strings (dot-operator variables)
  • followed by zero or one  } (closing unescape token)
  • followed by the string  }} (closing token)

Grammars can be wildly complex, but these simple principles can be applied to any of the templating frameworks to get a better understanding of how they work.


Regular expressions are not only useful for understanding how a templates syntax is structured, but are also used in parsing inline-token syntax templates.

Handlebars’ parser uses a technique which involves searching a template for the  {{ token, then “looking ahead” for the closing  }}, and saving everything between the two in a buffer. When the end token is found, the buffer contents are then parsed and types are returned based on their content.

The contents of those blocks are then passed again into the same parser, to look for further operators:

After the parser has finished iterating on the template string, it is left with a stack of logical operations and functions which are then supplied the data for rendering.

Consistency leads to Predictability

One of the keys to a language’s (and templating engine’s) success and adoption is consistency in syntax. Based on previous experience with a given syntax, a programmer should be able to successfully create new code without diving into the documentation. “If that similar structure took a key-value-pair before, I bet this one here does too.”

Inline-token syntax parsers self-enforce consistency of the language, due to the nature of the parser. It must find a specific token, followed by a set of allowable expressions, which themselves might contain expressions. It’s easy to remember that an underscore block always looks like this  <@= ... @>, because it must per the parser.

Element-attribute syntaxes have a harder time enforcing consistency, and it must be created through the framework creators insistence on following a pattern for their “language.”

A generic element-attribute syntax could consist of

Framework creators must choose a pattern for their element-attributes and insist that the pattern is followed for new directives that are added to the language.

Let’s create a pretend framework, called Bob. Bob’s starts simply, and only binds strings:

We continue to use Bob, and need to add some logic:

And later, repeating sections. Since repeat doesn’t really need a value, let’s write it like so:

Now we need to replace multiple attributes:

And finally, replace specific strings within attributes:

The moment a second programmer tries to implement Bob, it becomes clear that we’ve implemented a totally unpredictable syntax! Is a directive part of the attribute name ( bob-string="name"), or in the value ( bob="repeat")? What is the valid syntax for a  bob-bind attribute? A single value or a key-value pair? The  bob-replace value is JSON apparently?

Regardless of the frameworks speed or other technical features, a syntax implemented in this way will kill adoption.

Comparison of popular framework syntaxes

String insertion






That’s all folks!

Templating frameworks are very useful, and their syntax is one of the main way which a programmer interacts with them. Understanding the differences that syntaxes and template philosophies can help you choose the right one for your use-case!

Creating your own JavaScript Library – part 2 – Event Handling

write-your-own-javascript-libraryIn Part 1 of Creating your own JavaScript library, we cover the library essentials: library design, creating a solid object constructor, and adding functions by extending the object prototype. This post focuses on extending our basic library with event handling.

Out of the box event handling can be accessed  through Javascript and DOM apis, shown in the first 3 examples:

Simple event handling:

Assigning functions to events this way can be problematic, as only one function can be assigned at any given time. Mozilla Developer Network recommends that the addEventListener method be used instead, because of its flexibility.

Better Event handling

The addEventListener method accepts three parameters:

Assigning an anonymous function:

We can easily wrap this built in functionality with our library by creating a click function with a parameter that is passed to this native DOM event. This parameter will be an anonymous function (like the previous example) that will then bound to the element’s handler.

Handler wrapped by our library:

This pattern can be applied to any event natively exposed, such as:

  • onclick
  • onmouseover
  • blur
  • keydown

Non-standard or browser specific events

In the case where one browsers event api differs, it is simple to account for this in our event handler:

Optimizing our code

Instead of duplicating the addEventListener code in each event wrapper, we can optimize by creating an internal addListener(event, callback) function which will be called by other exposed functions, such as click, onMouseOver, etc

This separates the public wrapper from the internal event binding, allowing us to easily modify or expand the actual event binding code without modifying it in numerous places


Creating a microformat / richsnippits resume

What are microformats?

Microformats are small patterns of HTML to represent commonly published things like peopleeventsblog postsreviewsand tags in web pages.

Microformats are the quickest & simplest way to provide an API to the information on your website. See what else you can do with microformats.

Have you ever searched for a recipe on Google, and wondered how the highlight data like ingredients or cook time on the search results? Microformats. Or, wondered how they can aggregate reviews, locations, and prices for a restaurant search? Microformats.

Make your resume semantically searchable and available by implementing microformats.

There are several types we will implement from the microformat standard,, for fields on our resume:


Resume Sample

View the resume here, and a Google’s report on extracted data here.


Really Simple jQuery Tabs

Bugged by popular jQuery tab content rotators that a bulky, non semantic, to fast/slow, or can’t use custom HTML anywhere you want? Really Simple jQuery Tabs is a jQuery plugin that tries to address each one of those issues. It’s goal is to be as simple and flexible as possible. You can completely rip-out and replace the CSS with your own, changing elements position, styling, etc. It is quite small: at 844 bytes your bandwidth won’t know the difference!

And oh yeah: they rotate!

I have used several jQuery tab/content rotators/panels/things and, although each has been extensively developed and tested, am always left with the feeling that something is missing:

  • This one doesn’t let use put your own HTML in the tab-link
  • That one only supports images
  • The other one is 10,000 lines of code and you only use it once
  • This one cycles too fast/slow

The purpose of Really Simple jQuery Tabs is to be really simple and really flexible.

You can:

  • Add HTML to your semantically correct list item tab-links
  • Panes are regular DIVS – put images, text, AJAX loaded content, etc. up in that DIV
  • Specify (down to milliseconds) how fast to cycle, if you want to cycle at all
  • bonus feature: only 844 bytes!
  • Completely customize the CSS to affect layout, coloring, etc…

Before you get too far: Check out a simply -styled DEMO 

Or, see it in action at:

Implement it like this:

And the markup looks like this:

Notice that semantic markup? Yeah, me too. It was written to be as flexible and extensible as possible.

Now download the source and do your thing!

100% Height Div with 2 lines of code

2016 Edit: This post is really out-dated. If you are looking for a solution for 100% height divs, please use modern css as described here

EDIT: This post has several code-blocks of JavaScript to keep two divs at an equal height. I recommend the last method, if you are using jQuery — It seems to be more adaptive to different div content, working in more situations.

Check out the DEMO first, to see if this is what you want

The problem: Creating a div that auto-expands to 100% height of its container. The most common occurrence would be creating a two column layout for a menu, sidebar ads, etc…

The solution that never actually works:

“Since divs automatically inherit the height of their parent, if your parent doesn’t have height set, you cant get 100% of nothing. Set the parents height and it will work.”  Pshaw, I say.  While this may be the accepted standards mantra, I have never seen it actually work in a modern browser.

100 Percent Div Tutorial
Div! Y U NO Expand?!?

The Easy Solution (in 2 lines of code):

Working Demo on jsfiddle

Well, that’s actually 4 lines, if you include the script tag… But just 2 lines of JavaScript.

If you would like to keep the expanding div from collapsing too far, or expanding to much, simply add a conditional statement around the second line, like so:

Short Explanation:

Line 1 creates a new variable “h” and assigns this variable the height of an element found. This does not return the “height:” as specified in CSS, it returns the actual height of the document as it is displayed on the screen.

Line 2 fills the “height:” style value of the other, shorter, element with the variable h + “px”

Put this code near the end of your document, probably right before the body tag, and it will run right when the page loads. You could also wrap this in a jquery $(window).load, or even a $(document).ready. As it is, though, there is no library dependency – just plain-old-JavaScript!

Or, do it with jQuery instead:

Commenter Ivan couldn’t get this code working for him, so he rewrote it using jQuery. I have further rewritten his original code to be a bit shorter, and activate when the content of both divs has fully loaded. I recommend this method — if you are already loading jQuery — as it seems to work much better with dynamically loaded content.

Working jQuery demo


Edit #2 — There is a jQuery plugin called equalHeight that accomplishes this pretty easily

Check out my post 100% height using jQuery for more information about it.

Hacking MyMathLab (a case study in software security best-practices)

This article details an experience I had while using the software MyMathLab, and overviews software security best practices. There is no information in this article that would allow students to alter their grades or cheat in any way, but details minor exploits in the software and security infrastructure related to “locking down” a workstation. This post was written for educational purposes relating to software development and security.  

In keeping with security best practices, the software vulnerabilities were immediately show to both a math faculty member and a campus IT employee sometime before being published in this article.

MyMathLab is a software product, owned by Pearson (one of the largest textbook publishers in the US), including:

The Art Institute of  Houston, ASU, Baker College, Boise State University, Bossier Parish Community College, Cabrini College, Central Texas College, Chicago State University, Cleveland State Community College, Coastline Community College, College of the Sequoias, DeVry University, Florence Dablington Technical College, Florida State College at Jacksonville, Front Range Community College, Henry Ford Community College, Hillsborough Community College, Houston Community College, I State, Ivy Tech Community College, Jackson State Community College, Kapi’Olani Community College, Lone Star College Montgomery, LSU, Memorial University, Mesa Community College, Mississippi State University, Norwalk Community College, Odessa College, Quinsigamond Community College, Reading Area Community COllege, Riverside Community College, Rock Valley College, Sait Polytechnic, South Suburban College, Southern Illinois University, The University of Alabama in Huntsvilee, Triton College, Umpqua Community College, University at Albany, UHD, University of Idaho, UIC, The University of Mississippi, UT, The University of Toledo, University of Wisconsin-Stout, Volunteer State Community College, and Yavapie College

Why I Tried:

During the first-day-of-class-reading-of-the-syllabus my professor came to this line: “Do not use the computers in the classroom or math lab to use email, or use any other non-math website.” “Actually,” he said, “I’m pretty sure that the computer department locked down all of the computers, so why don’t you try, if you can actually get anywhere I’ll be pretty surprised, but come and show me.”

Challenge accepted!

MyMathLab Opening Screen

During my first glance around the software, I gathered some basic information:

  • MyMathLab is a web-application that allows students to
  1. read from an e-text (a pdf)
  2. watch video examples (in quicktime)
  3. do homework in a flash application
  4. watch math presentations (powerpoint)
  • MyMathLab runs in a stripped down version of Internet Explorer.
  • The entire computer seems to be under the control of some type of user-access control system. Attempts to click on the start-bar or the windows time are met with an “Unauthorized Function!” dialog box. I seem to be completely sand-boxed in.
  • There is no physical tower, or box powering my monitor, keyboard, or mouse. I seem to be using a terminal that connects to a MyMathLab server somewhere else on campus.

Thinking back to my experience at a highly micro-managed yet highly incompetent call-center, I remembered that my first, and probably easiest route to escape would be to find a dialog box that I could hijack and turn into a make-shift explorer window. From there I could navigate to anywhere I had permissions.

Failure 1: The weakest point in any system is the reliance on any third-party controls or software to perform a critical function.

Administrators will perform their due-diligence in locking-down any user access that they have created, but often fail to check, or even understand third-party systems that they give rights to — assuming that the third-party system will always behave.

This route of attack was remarkably simple, yet yielded a remarkable amount of access.

Step 1: find a dialog box

While the quicktime tutorials and the pdf e-text both opened in a custom reader, or at-least a custom shell of a known reader, the slides opened up right in a fully-featured Powerpoint session. I was a little surprised! I first went for the “open” button, which led to a “Unauthorized Function!” message. Good Job, guys. Open Recent and Save As were both dead-ends too.

“Let’s get creative,” I thought, and created a new document. That worked!  I noticed that more of the ribbon appeared — I must have been looking at a read-only version of the math slides. Now I see more font control, as well as some shapes, as well as more buttons along the ribbon: Insert, Design, Animation, Slide Show, Review, View, and Format.

The Insert tabs looked like a gold mine: insert videos, images, objects(ole I’m assuming), etc.  Inserting an image finally led to my dialog box!

Step 2: Explore Access.

I held back my hopes as the Image dialog box opened for me.  A couple things could still go wrong at this point: I might only have access to my sessions Documents and Settings Folder or the file-type could be restricted to images only. I held my breath and click on My Computer on the left of the dialog box…

Oh. My. Word.

  • C:/MyMathLabServer
  • Network Places

To test out my permissions, I right-clicked, created a new text file, and then proceeded to delete that file. Success.

Failure 2: Giving the user write permissions to system critical files.

Now for a look around: C:/ had all the normal stuff: program files, windows, documents and settings.

The most I dared to do was to open one the the DLL files in program files/mymathlab with notepad and make a small change in a comment section, save it, and then change it back after checking to see if it worked. It did.  I also had access to the host-file entries that prohibited any access servers other than mymathlab.  Probably the most damning however, was my ability to open the command prompt, which allows nearly unrestricted access to the inner workings of the local network, as well as the local workstation.

Failure 3: The workstation user account had access to the command prompt.

After class, however, my inner white-hat prevailed, and I ended up telling my professor what I had found, who then nearly sprinted up to the CS support lab and dragged a tech down for me to walk through my simple exploit. And seeing as I gave CS support adequate warning about the exploit, I now have no qualms about sharing my story, because I’m sure its fixed by now!

The moral of my story? Don’t be a bad programmer, don’t rely on third-party software/controls for essential functions, and most of all: don’t try and lock-down students, it just makes them curious.