Jelly: Deep Dive Series...

[SlightlyLoony]

A few weeks ago, a friend and colleague asked me to do a series of posts on Jelly, because he knew that many people found it quite mystifying — not only how to use it, but even simply what it was.

The first time I ran into Jelly, I didn't have a camera around — but I think my face must have looked something like the fellow at right. I'll let you fill in the internal dialog 🙂

But, in fact, Jelly really isn't that hard to understand. It's definitely different, but truly it's not terribly difficult.

So this is the first post in a series on Jelly, and I'll start from a high-level view and work down into the teensy little details...

What is Jelly, anyway? It's an open source technology (from the Apache Foundation) that the ServiceNow instance uses to render (i.e., produce HTML) web pages. ServiceNow has enhanced standard Jelly to add even more capabilities.

Ok, but what does Jelly actually do? The end product of Jelly is HTML (i.e., the contents of a web page), plain and simple. That's the easy part! Jelly produces HTML by interpreting a Jelly template, which is itself an XML document. Jelly templates have their own very specific set of XML tags and syntax, but they also directly incorporate the HTML tags that will be produced as output. The special Jelly tags do all sorts of handy things, including some things that look a lot like a more conventional programming language, the ability to use data from the ServiceNow instance, ways to execute JavaScript (on either the web browser or the ServiceNow instance), and much more.

This is shown graphically at right (click to enlarge the diagram). The process works like this, conceptually (don't worry about the details at the moment):

1. Request: A web browser sends a request to the ServiceNow instance. The URL is for a web page that will be rendered with Jelly (not all ServiceNow URLs result in using Jelly, though most do).
2. Jelly template selection: The ServiceNow instance uses the particulars in the URL for the request to select the right Jelly template to use for rendering the particular page.
3. Jelly interpretation: The Jelly engine is invoked with the selected template, and the template is processed to produce the output HTML. There are many details about this process that we'll cover in later posts. For now, just note that the Jelly engine can access data from the ServiceNow instance, and use that data either as content in the output, or to make decisions about what to output.
4. Response: The output HTML is transmitted back to the requesting web browser.

There, that wasn't so bad, was it?

I'll end today's post with a very simple sample of a Jelly template. You can paste this into a new test UI page (System UI → UI Pages) yourself and try it:

<?xml version="1.0" encoding="utf-8"?>
<j:jelly>
       <j:set/>
       <j:while>
             
Test
               <j:set/>
       </j:while>
</j:jelly>

I'm not going to cover the details of this sample in this post; this is just a sample to introduce you to Jelly's appearance.

If you actually render this Jelly (by testing it in a UI page), you'll get this HTML:

Test

Test

Test

All those special Jelly tags are not themselves included in the output. But...the HTML tags are included — in fact, they're repeated three times. Can you see why?