BC.NEXT - New Module/Tag Syntax, Liquid Templating and Improved Rendering Performance

Cristinel Anastasoaie - Tuesday, June 17, 2014

With the upcoming release of the new BC rendering engine, we are launching some very exciting features that will allow partners unprecedented control over the module layouts and templates along with great readability of BC code.

Module syntax improvements

The first  improvement is the way we render modules to enable usage of modules in modules. We've also re-vamped how <head> elements are being collected and included in the final page - and while the new solution is more elegant, you should be careful in how you test existing sites as the behaviour might be changed.

In the same light, we always knew that the current module syntax is cryptic. There are IDs everywhere. Commas ",,,," everywhere. Conventions everywhere instead of a simple to read named parameters approach.

We have received positive feedback in the past when we changed the menus syntax with a more readable one, so we have decided to make the BC markup a really easy to read syntax. We are now introducing named parameters to all modules. This will allow you to read way easier how a page is constructed.

Before:

{{module_news,r,,true,ajax,_blank,,,,,date reverse}

Now - note that most parameters are optional and you don't have to use a list of commas and respect the parameter order:

{{module_news filter="random" notemplate="true" effect="ajax" target="blank" sortType="date reverse"}

We have also improved the module in modules extensibility - several new modules are now supported. {module_pagename }, {module_isloggedin } and {module_pagetitle } can be used in other modules.

{{module_news filter="random" template="{{module_isloggedin}.tpl"}

We're also continuing to collect your feedback on new tags and tag improvements. More to come on this track as we see this new rendering engine in good shape.The module reference will also be updated with the upcoming release to include the new module parameters along with the old ones.

Announcing Liquid templating engine support

In order to get the best flexibility and ease of use, we chose the Liquid markup language (http://docs.businesscatalyst.com/developers/beta/introduction-to-liquid) to enable great control of the layout and templates along with great ease-of-use.

We aimed at creating an engine that is backwards compatible, so do you don't have to change your existing sites (if you don't want to) to take advantage of new liquid features. In the same spirit, we want to make it easy to adopt - you will be able to add a liquid "if statement" in an existing template and it will work without having to change the rest of your module layout. And in terms of approach, we are implementing it in a surgical way, using the new BC rendering engine and current tags as a data collection mechanism, collecting all the data, and then exposing it to the Liquid engine. 

Liquid will give you a lot of power to build sites on BC. Here are several things you will be able to do, but we are sure you'll be able to do so much more:

  1. Use the new readable tags with string formatting capabilities
  2. Access {{globals}} and {{user.globals}} - variables to allow complex conditions
  3. Conditionals in pages or email campaigns to generate dynamic content depending on the user
  4. Take over any BC generated markup and replace it with your own markup to free you from our generated code limitations
  5. Enable looping over data collections to allow you to display data in your own format.
  6. New readable tags with string formatting capabilities

In all the module layouts, you are now able to use both the old tags and new liquid-data tags. For example, in the {{module_news} list layout you can use both { tag_announcementid } and its liquid equivalent {{id}}. The same goes for {{url}}, {{subject}}, etc.

You can benefit in this way of both full-backwards compatibility and the advantages that liquid brings (string formatting, conditionals, etc) like in this example: {{body | upcase}} which outputs with the body in upcase.

More information about liquid filters you can find here: http://docs.businesscatalyst.com/dev-assets/reference/liquid-reference/reference/supported-filters-and-operators.html?beta

Globals and User globals

A series of global variables are now available in the Liquid rendering. Some of these are:

  • global.user - If a user is logged in, this global variable will contain information on the customer that is logged in your site: {{globals.user.fullname}}, {{global.user.firstname}}, {{global.user.lastname}}, {{global.user.email}}
  • global.site - can access site information such as: {{global.site.id}}, {{global.site.name}}, {{global.site.contryCode}}, {{global.site.host}}, {{global.site.language}}
  • global.visitor - can access information on the user-agent such as: {{global.visitor.deviceClass}}, {{global.visitor.ip}}, {{global.visitor.country}}, {{global.visitor.userAgent}}
  • global.get - you will be able to access GET parameters in your liquid markup like this: {{global.get.mygetparam}}
  • global.cookies - you will be able to access cookies in your liquid markup like this {{global.cookies.mycookie}}

Conditionals in pages or email campaigns

With access to data and Liquid you will be able to add your own logic in pages.

For example in a page you will be able to check if a GET parameter was passed to the page and do your own logic accordingly:

{% if globals.get.mygetparam %}
     A GET.mygetparam parameter was passed to the page and it has the value: {{globals.get.mygetparam}}
{% endif%}

Or take over any BC generated markup and replace it with your own markup and looping over data collections.

The new rendering engine allows to capture the output of basically every module and use the data of that module in any way you want. Here's an example of how to do that:

{{module_announcement filter="all" template="" collection="announcementCollection"}
<p>module name: {{announcementCollection.moduleName}}</p>
<ul>
    {% for news in announcementCollection.items%}
    <li>{{news.id}} - <a href="{{news.url}}">{{news.subject}}</a></li>
    {% endfor %}
</ul>

Notice that the "template" parameter of the module is left blank and that a new parameter called "collection" is added.

The empty "template" parameter tells the module to suppress any output and the "collection" parameter indicates that instead of outputting the data it should gather it in a collection.

This way all data of the module is accessible in the "announcementCollection". Modules have various data added there. In our case the collection will contain a "moduleName" and a list of announcements put nicely in a collection that you can loop through: "items".

You can loop through items and access all the properties of every item using the same names as you would have used them in the actual module layout (id, url, subject, etc).

Some modules even contain properties that include the navigation information when it exists in the module (such as properties called prevUrl, nextUrl which contain links to the previous or next page).

Suppressing the BC injected JS/CSS files (modulestylesheets.css, etc)

Every time BC outputs a page, it also adds into the HEAD various stylesheets and JS files needed for the various modules and BC functionality to work or render nicely. For example if I create a simple page that would only contain {{module_pagename} and even set that it would not use any template, the page would automatically have inserted the following lines:

<link href=" /StyleSheets/ModuleStyleSheets.css" type="text/css" rel="StyleSheet" />
<script type="text/javascript">var jslang='EN';</script>

Same thing happens with more complex modules like shopping cart, etc., where more dependent files are added to the page. Partners asked us to be able to fully control all the CSS/JS from a page and allow suppressing this automatic output and let them add their own links in the page template.

For this, we have added a new property to the Page Templates, which can suppress any JS/CSS inserted either by merging the page with the template or by any other modules added to the page.

So for the example above, the only thing that the rendered page would contain would be just the page name.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns=" http://www.w3.org/1999/xhtml ">
<!-- BC_OBNW -->
<head>
<title>My Page with noCssJS</title>
</head>
<body>
        My Page
</body>
</html>

This would allow you to control even the JS/CSS in the e-commerce, blogs, and any other sections of the site that use that site-wide-template - of course this means you will need to to manually re-insert any required JS files as otherwise the functionality might break (add to cart, etc).

Improved rendering performance

Another area where we looked at the rendering engine was around page loading performance and Google PageSpeed score results for BC - also making sure that Liquid pages continue to render very fast. In this direction, we're making several improvements.

For dynamic page content, the output of all pages rendered (any page with modules in it) will be cached in memory for faster serving, with the cache being invalidated when a change is made to the site. This more than doubles the page generation speed for most use cases, while protecting our servers to large loads (better handling of traffic spikes when featured on TV or during attacks). We are also giving you the option of disabling page caching in custom cases using a special module.

For static page content, we have received complaints in the past that we're not sending the correct headers, having Google PageSpeed complain about this and giving BC SEO warnings. We're fixing this with the introduction of a new way to enable better headers for most static assets that we can intercept at rendering. For example, a static asset will be always appended a unique version number that is linked with the static asset content, to make sure everywhere a static asset is changed (either by you developing or by your customer when uploading a new product image), we always serve it again and the browser knows that the asset has changed.

Before:

<img src="/logo.jpg"/> Cache-Control: private, no max-age

Now:

<img src="/logo.jpg?bc_t=5kokdQz9hN1S0v26vVI5DQ"/> Cache-Control: public, max-age=2592000

Finally, we are upgrading our infrastructure to the latest Amazon machines, the latest OS versions and application server version to benefit from the advancements in the field.

We are very eager to get these in your hands soon to see what amazing things you can create,

The Adobe Business Catalyst Team.

Comments