Glossary and other changes

2019-04-29

We have released a Glossary of terms built with two use cases in mind:

• to look up unknown words as you bump into them, and

• to read the Glossary in one go to get a better understanding of the system.

We rolled out some related (and some unrelated) changes as well, you can learn about them below.

Changes

Changes to our vocabulary had to be reflected in our codebase. Here is an overview of the major changes.

Placeholder -> placeholder, bucket, bucketId

As the system evolved, so did the meaning of some terms. The term placeholder was used to refer to both drop-zones on pages and the corresponding containers which are organizing a file’s children. It became obvious that the two are different things, so we needed two separate words to reflect the subtle differences in meaning.

On the filesystem, we now have buckets. The numeric IDs identifying buckets are now called bucketIds.

The term placeholder will continue to be used for content drop-zones on pages.

This change was rolled out system wide with no breaking changes.

• The sjs-3 engine now supports the File.prototype.bucketId() method in addition to the File.prototype.placeholder() method which became deprecated but remains supported.

• The accept-1 built-in type used attribute names containing the term placeholder. We introduced an accept-2 type that uses attribute names containing the term bucket instead.

App -> app, package, source

The term app refers to an application. As we rolled out the package management system for Boomla, I made the mistake to assume that each website will contain a single app, so I named them app webstes.

In practice, multiple apps are often packaged together in a single website, so instead of using the term app website, we will use the term package website, or simply package.

The default install location for such dependencies was the /sys/apps file, which has now been changed to /sys/packages. To have no breaking changes, the system will first look for packages in the /sys/packages file, then in /sys/apps.

In the sjs-3 engine, we also had a variable named app which referred to the source file holding the JavaScript code. The history of this variable dates back to the early days when Boomla had a completely different runtime. From now on, the variable app is deprecated, you should use source instead. Again, both variables will live on, this is not a breaking change.

.Trust -> .ContentSecurityPolicy

Instead of using a file named .Trust for storing Content-Security-Policy rules, we will from now on use a file named .ContentSecurityPolicy.

This is not a breaking change, as the .Trust. file will continue to be supported.

To dynamically set Content-Security-Policy headers on the HTTP response, you can decorate the content-security-policy attribute of the response file.

Content-Type now optional in .Request methods

Up until now, one had to always set the content-type attribute of response files. Let’s face it, most of the time when writing code, we use text/html. So from now on, Boomla will default to this setting - but you can always override it.

Removed support

The following changes did not affect the current version of any website in the Boomla Cloud, but I’m documenting them anyway for reference:

• the sjs-2 engine was removed,

• .Class and .Style file support was removed.

These were deprecated about 2.5 years ago and all websites have been migrated back then. This means not only are current website versions not broken by this change, but each has a 2.5 year long fully functional version history. Versions prior to that would have to be updated to work again.

Migration scrips

Here are some helper scripts to help your migration if you decide to upgrade your website to use the new terminology: