11 Days of Salesforce Storefront Reference Architecture (SFRA) — Day 11: Playing With Templates
Tags: salesforce, sfra, sfcc
Published: 2020-05-20 06:29:14

---
title: 11 Days of Salesforce Storefront Reference Architecture (SFRA) — Day 11: Playing With Templates
published: true
date: 2020-05-18 19:01:36 UTC
tags: salesforce,sfra,sfcc
series: 11 Days of Salesforce Storefront Reference Architecture (SFRA)
canonical_url: https://medium.com/perimeterx/11-days-of-salesforce-storefront-reference-architecture-sfra-day-11-playing-with-templates-75180a7d48df
---

### 11 Days of Salesforce Storefront Reference Architecture (SFRA) — Day 11: Playing With Templates

![](https://cdn-images-1.medium.com/max/1024/1*mY4tYAWObMEtg08OE_ddCQ.jpeg)<figcaption>Photo by <a href="https://unsplash.com/@picoftasty?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Mae Mu</a> on <a href="https://unsplash.com/s/photos/manipulation?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption>

Time flies when you’re having fun. Today is our last stop on the SFRA development train, and its an exciting one for sure! In today’s post, we will play around with ISML templates, or in other words, the visual representation layer of our storefront.

### Let’s Talk About Cache, Baby

Templates are used a lot, but by default, they are **not** cached. That being said, there may be times where we want to cache the template for better performance. For cases like these, ISML comes to our aid with the `iscache` element. The `iscache` element should be placed at the top of the page and enables us to set cache on a template and configure it, using a number of properties, to suit our needs:

- **Status** : A boolean flag that enables/disables page caching. Since caching is disabled by default, just the presence of the `iscache` tag implicitly enables page caching.
- **Type** : A required property that sets the type of cache being used. The values for type can be either `relative` or `daily`, the former allows us to specify a period of time (in hours and minutes) for the page to be deleted from the cache, and the later allows us to specify a specific time in the day when the page will be deleted from the cache (eg. 3 am).
- **Hour** : When the cache type is set to `relative`, the `hour` property represents the duration in hours before the page is cleared from the cache. When the cache type is set to `daily`, the property represents the hour of the day (in 24h format) when the cache will expire.
- **Minute** : When the cache type is set to `relative`, the `minute` property represents the duration in minutes before the page is cleared from the cache. When the cache type is set to `daily`, the property represents the minute of the hour in the day when the cache will expire.

> 🐘 The `iscache` element has two additional properties which are beyond the scope of this post: `varyby` and `if`. If you like to learn more about them, head over to the official [SFCC documentation](https://documentation.b2c.commercecloud.salesforce.com/DOC1/topic/com.demandware.dochelp/ISML/ISML.html?resultof=%22%69%73%6d%6c%22%20).

**Go Wild 🌈**

Consider the following tag:

```
<iscache status="on" type="relative" minute="15"/>
```

This will cache the page for a period of 15 minutes (notice the use of `relative` and `minute` here).

Another example would be:

```
<iscache status="on" type="daily" hour="21" minute="30"/>
```

This tag uses the `daily` type, which means that the hour and minute properties represent an hour in the day (9:30pm in this case).

### A JSON Response

Not all templates have to be visual. There may come a time when you would like to return a JSON object as your response (for example, an API route). Up until now we only used `res.render` to render our responses to the client, however `res` has another card up its sleeve: `res.json`. Using `res.json` allows us to render a JSON object directly, without the need to add any ISML templates or set the content type of the response.

On the Magic controller (located in our Magic cartridge controllers folder) add the following route:

{% gist https://gist.github.com/pxjohnny/547843c7a1c76c147679fc53e23c224c.js %}

The code looks similar to our Show method, but instead of rendering it on the page, we render the response from the [icanhazdadjoke](https://icanhazdadjoke.com/) service directly on the page using `res.json`!

**Go Wild 🌈**

If you navigate to the **/Magic-Json** route (don't remember the full URL? head back to [Day 4](#) to refresh your memory) and you should see something like this:

![](https://cdn-images-1.medium.com/max/1024/1*QN_Xn7Vp_V6ExmyK9YYS-A.png)<figcaption>Our joke JSON in all its glory! 🎉</figcaption>

### Overcoming the Language Barrier

Internationalization is another important concept for our storefront, as it allows us to provide content to visitors in more than one language. ISML templates support this concept using a feature called `properties files`. So what are these magical files? Well, nothing more than a dictionary of key/value of text really. Let’s create a new template on our Magic cartridge called **hello.isml** that initially have the following content:

{% gist https://gist.github.com/pxjohnny/fc73925fd7b9ad1240f856155a31870b %}

As you can see, it’s a pretty basic (and ugly) template that shows a header and some text. Now, this text only caters to an English speaking audience, but what if we want to show a visitor whose browser language is Spanish the same text in his native language?

If you look closely at the **templates** folder of our cartridge, you’ll notice a folder called **resources**. As the name suggests, this folder holds the resources (or language) files for our template. Let’s create a default language (a.k.a properties) file in the folder that will hold the English text. Create a new file called **hello.properties** inside the **resources** folder with the following content:

{% gist https://gist.github.com/pxjohnny/b94e7a1812326772bbc8ae677d4e4205 %}

This is the same text as we had hardcoded on the **hello.isml** template just a moment ago. Let’s update our template to actually use the properties file:

{% gist https://gist.github.com/pxjohnny/6181e230c522a003c1cbc1e9ada70c6c %}

So what do we have here?

**Line 9** : We replaced the hardcoded text with the `msg` method of the `Resources` object in order to display the text from a resource file. The method takes three arguments:

1. The key to the text we wish to display.
2. The name of the properties file to use.
3. The default value to display. In this example, I left it as `null`.

**Go Wild 🌈**

If you browse to a route that uses this template you will see it just like before:

![](https://cdn-images-1.medium.com/max/1024/1*KAigK0v7e_175uyXFTIzEA.png)

Now, let’s add another file named **hello\_es.properties** in the resources folder:

{% gist https://gist.github.com/pxjohnny/71b40cdd55691720e3074e867b045c49 %}

And that's it! if a Spanish speaking visitor comes to our site, he will see the translated text:

![](https://cdn-images-1.medium.com/max/1024/1*Jl1Q8-5mf97k9Om5pQPDtQ.png)

You can have as many properties files as you wish to support different languages. There is virtually no limit to the internalization you can have on your storefront.

### Epilogue

This brings our journey with SFRA to its final destination. I hope I managed to show you at least one cool aspect of the SFCC platform you didn't know before, and as always please contact me with any comments or suggestions either here or on [Twitter](https://twitter.com/fullstackj). I look forward to hearing which day was your favorite 😎

* * *