10 Must-Knows About Sightly

Since AEM 6.0, Sightly is available as an alternative to JSPs and JSTL for templating. One might wonder why Sightly is a product specific templating language.

Sightly as a product specific templating language should be used instead of a standard like JSP and JSTL. Some of sightly's advantages Adobe points out – aside from ‘being pleasing to the eye’ – include higher security, separation of concerns and HTML5 compliance.

Sounds good, and at Netcentric we favour Sightly over JSPs and JSTLs. After getting great responses to our Sightly style guide we wanted to share ten crucial points to know when working with Sightly, ranging from technical odds and ends to more general considerations.

1. Separation of concerns

One of our key drivers for adoption. Before using Sightly we always needed to write all templates in JSTL, because JSP's logic tends to sneak into the views (who never had this issue, raise your hand!). But JSTL can become rather unwieldy and produces lots of clutter. This is very much reduced in Sightly, and it really bridges the gap between back end and front end development.

2. Context

Sightly escapes almost everything, which is pretty awesome, since this makes secure renditions the default. But it might be confusing, if you e.g. want to include dynamic stylings. Think of this

<h1 style="${important? 'color:red' : 'color:grey'}">${text}</h1>

Looks pretty nice, but doesn’t work, as Sightly recognises the CSS style and removes it as potentially harmful content. Add the context like this, saying ‘I actually want to deliver style information here:

<h1 style="${important? 'color:red' : 'color:grey' @ context='styleToken'}">${text}</h1>

Et voilà, it renders nicely.

3. Integration with sling models

Now, that headline is awfully wrong. Sightly does not require Sling Models – there are actually five ways to get your logic into Sightly. Still, Sling Models is the perfect way to set the Java logic up. You can refer to the model by including it like this:

The variable ‘myComponent’ is now instantiated with the MyComponent model.

4. Syntax

This actually took me some time to wrap my mind about. Lets assume you want to add logic to an HTML tag in Sightly, like a test when to render it. Then you can think of it like a method call, which you can set up as follows:

data-sly-<directive>.<return value>="<parameters>"

This is not entirely true, but an analogy that will help you in the first days. Let’s try it with the following expression:

<h1 data-sly-test.title="${myComponent.showTitle}">${title}</h1>

You are calling the test directive of Sightly, passing the showTitle property of the myComponent object as a parameter. The result is stored in the Sightly variable title (and applied to the h1 as well).

5. Templates

No, I’m not talking about the templates in general, but about the templates in the templates, like in Inception. Templates define re-usable and potentially recursive methods in Sightly. They can be defined locally or in separate files. Define a template:

<template data-sly-template.titleRenderer="${@ titleParameter}">
<h1>${titleParameter}</h1>
</template>

And then use it:

<sly data-sly-call="{titleRenderer @ titleParameter='Title'}" />

If you defined the template externally, make sure to reference it with the additional tag data-sly-use.template = "file.html", which will give you a variable called ‘template’ that holds all templates defined in the external file.

6. Version diffing

This is an ugly one. Version diffing is a core feature of AEM and used in many websites. It includes HTML to highlight changes in different versions of the page directly in the author environment. That’s pretty neat, but by inserting HTML into text – well, the text becomes enriched with content that is automatically escaped by Sightly. So you actually have to skip all the encoding. Which again takes away a core feature of Sightly. Adobe is working on a solution for this.

7. Do it in style!

What I really like about developers (those at Netcentric, at least), is that they care about the code they write. It not only has to work, we also want it to look pretty – sightly so to say. This is especially important regarding the broken windows problem. Therefore, hand out our Sightly style guide early in the project. Now, if the developers would be as thorough when putting away their coffee cups …

8. Localising terms

i18n is something basically every website running on AEM needs, as most drive multinational and multi-lingual sites. Sightly makes it really easy and beautiful to localise terms provided in dictionaries: Just add the context i18n.

9. Finding the compiled source

Compiled sources used to be in CRX itself, i.e. below /var/classes/slightly. This changed in AEM 6.1 for performance reasons. It’s a bit of a shame; I really liked looking up the generated servlets for debugging. Now it’s a bit more tricky to find the source code as you actually have to identify the bundle ID of the FSClassLoader bundle, and then you have to look it up in the file system.

10. Adoption

We’ve heard the ‘yet another proprietary templating language?’ quite a lot. But in my experience, Sightly really is a boon to projects, especially as it allows front end developers to directly work with the templates in AEM, and not having the visual clutter of JSTL or the power (and responsibility!) of JSPs. We use it in all our projects, on AEM 6.

Sightly developing guides

Adobe has very good guides about developing components using Sightly, and if you like please feel free to contribute to our Sightly style guide project on GitHub!

style

dark-plum