Additional updates to liquid to be released in March

With our R213  release, scheduled for March 2016, we're going to push some updates that aim to solve some of the consistency or redundancy issues currently present in our liquid beta implementation.

Consistent pagination across all modules

Today, the pagination across some of the BC modules is highly inconsistent and offers different level of support depending on the module it's implemented on. We want to change that so that all modules outputting paginated data  expose a metadata object named "pagination" with the following fields:

• previousPageUrl, nextPageUrl - for the modules that expose paginated data but for which the concept of previous and next page might not make sense, these fields will be set to null
• currentPage, numberOfPages - numeric values, mandatory. currentPage represents the current page number, using 1 based indexing
• itemsPerPage - numeric, mandatory [new]
• totalItemsCount - numeric, mandatory [new] - also requested here: https://forums.adobe.com/ideas/4547

While previousPageUrl, nextPageUrl, currentPage and numberOfPages are already exposed by some  modules, itemsPerPage and totalItemsCount are new fields that aim to make it easier for partner to handle module output.

As such, the modules below will be updated for pagination metadata consistency:

• Search results - added itemsPerPage and totalItemsCount. previousPageUrl and nextPageUrl will be set to null instead of string empty when there is no previous / next page available.
• FAQs  - added currentPage, numberOfPages, itemsPerPage and totalItemsCount. previousPageUrl and nextPageUrl will be set to null instead of string empty when there is no previous / next page available.
• Web apps  - added itemsPerPage and totalItemsCount
• Blog details - added currentPage, numberOfPages, itemsPerPage and totalItemsCount. previousPageUrl and nextPageUrl will be set to null instead of string empty when there is no previous / next page available.
• Products - added currentPage, numberOfPages, itemsPerPage and totalItemsCount. previousPageUrl and nextPageUrl will be set to null instead of string empty when there is no previous / next page available.
• module_productresults - added all pagination metadata fields
• tag_commentspaged from blogs -  added all pagination metadata fields
• Photo gallery  -  added all pagination metadata fields. The current pagination method will continue to work for the moment.

Important note: while the change is  backwards compatible for most modules, there are three modules (listed below) where the change is going to break the compatibility:

• or module_blog, overall layout:
  • If there is no previous page,  previousPageUrl will be null instead of “#”
  • If there is no next page,  nextPageUrl will be null instead of “#”
• for module faqresults
  • If there is no previous page, previousPageUrl will be null instead of “”
  • If there is no next page, nextPageUrl will be null instead of “”
• For module searchresults
  • If there is no previous page, previousPageUrl will be null instead of “”
  • If there is no next page, nextPageUrl will be null instead of “”

To prevent any navigation issues, please update your sites prior to the release to take this change into account.

Data type updates for  custom web app fields in list layouts

Currently, in web apps detail layout, numeric, boolean and datetime values respect their type. In the web app list layout they are captured as string. With the R213 release, we're going to adopt a consistent behaviour for both cases.

Important notes:

• Uninitialized numeric, boolean and datetime custom fields will have their value set to null instead of the empty string. If you were relying on an empty string output, you need to update your sites to take this change into account (ex: a liquid code sample that would work with both the current and the R213 release would be: {% if myVariable and myVariable != "" %}).
• additionally, when no filters are applied, datetime and numeric types will be rendered using their default Liquid formatting (numerics are rendered using two decimals and datetime fields are rendered using the ISO 8601 format). To prevent any issues with the site's output following the release, it is recommended that, prior to the release, you convert those fields to their correct types date and number filters to control the output. More information about liquid filters can be found here: http://docs.businesscatalyst.com/reference/liquid/filters.html

Removing unnecessary data from modules in Liquid

As previously mentioned on this forum thread (Removing unnecessary data from modules in Liquid), we're planning to remove some of the unnecessary data outputted by liquid modules. Please find below a list of what's scheduled for removal.

1. editableFieldTypes from module data

Many modules include an object named editableFieldTypes in the data they make available for Liquid. Below is an example of the editableFieldTypes object generated for events (bookings):

"events": {
  "moduleName": "booking",
  ...,
  "editableFieldTypes": {
  "body": "Html",
  "id": "Id",
  "name": "Text",
  "date": "Date",
  "capacity": "Number",
  "percentFull": "Number",
  "capacityEmpty": "Number"
}


These editable fields are a reminiscence from a feature we previously experimented with but  never made it to production. They are of no use at the moment and just pollute the output of |json.

2. Unused fields from moduleDescriptor

In Liquid, each module contains a metadata object called moduleDescriptor. For example:

"events": {
  "moduleName": "booking",
  "moduleDescriptor": {
  "templatePath": "/Layouts/Booking/list.html",
  "parameters": "filter=\"all\",collection=\"events\",template=\"\"",
  "apiEndpoint": "/api/v3/booking",
  "objectType": -1,
  "objectId": -1,
  "adminUrl": ""
}


With the release, we're going to remove the following fields from the moduleDescriptor: apiEndpoint, adminUrl. adminUrl are unusable for the vast majority of modules and the apiEndpoint is probably not really useful as a field in the content rendered by a module. objectType and objectId will not be removed for the moment, but we do not plan to support them in the future.

3. _raw date fields generated by modules

For date time fields, most modules also output a _raw version which is the same as the normal version except that it isn't converted to the site's time zone. Instead it always uses the Sydney timezone without daylight saving. _raw date time fields were  useful in the older days of Liquid in BC when we didn't have proper data type and handling and no format filters for dates, since _raw fields were in a format that was easier to use in JavaScript. However, nowadays they are just redundant and in many situations inaccurate and thus we are removing them.

To avoid any problems with your sites, please make sure you update the pages using the changed functionality by March 10th.