SFCC Storefront

This article is in continuation to our earlier post “Intro to Salesforce Commerce Cloud (Demandware)”. In it, we learned about the what, why & how of SFCC. Now that we have access to a sandbox, let’s dive into the technical details of a storefront.

Before we get coding, we need to know the basics of what a storefront is made of. Well, a storefront is just a website. So when it’s rendered in a browser like Chrome, it’s just a bunch of JS, CSS & HTML. Let’s look at how each of these components came to be. In order to get these pieces to the client (browser), there’s a lot going on in the server.

JS

Client-side JS is authored directly by the developer, without the involvement of any tools or frameworks. These are scattered over several files, each focusing on a specific functionality. However, these aren’t referenced directly in the storefront. These are combined by Grunt into a single minified file named app.js, which in turn is included in the common footer used across all pages of the storefront.

CSS

Style sheets start out as SCSS files. This lets us use awesome features like variables, nesting, mixins & inheritance in our style sheets. Just like the JS, these too are split over several files, focusing on specific functionality or style areas. Once again, Grunt is used to combine these into a single minified file named style.css, which is included in the site header.

HTML

The pages that make up the storefront, are written in a dynamic templating language. These get processed into HTML pages when a user requests for them. The templating language used, is proprietary to SFCC & is called the Internet Store Markup Language (ISML). An ISML file is written just like an HTML, using tags that accomplish specific tasks. All HTML tags are allowed in ISMLs. In addition, ISML defines its own tags for SFCC-specific functionality. All ISML tags have the prefix “is”: <isprint>, <iscache> & so on.

MVC

SFCC uses the MVC architecture & as such, uses “models” to manipulate data, “views” to display data & “controllers” for the business logic. ISML is the view. The models & controllers are implemented as server-side JS modules. Each controller maps to a URL. When the user enters a storefront URL in their browser, or performs an action on the storefront, a controller is triggered. The controller executes the business logic, creating & using instances of models as needed. Eventually, the controller renders an ISML as a response to the user request.

About Author:

K. M. Harish is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, he actively contributes to the areas of Technology and Information Security. He can be contacted at:  harish.km@spluspl.com