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 to our vocabulary had to be reflected in our codebase. Here is an overview of the major changes.
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.
sjs-3 engine now supports the
File.prototype.bucketId() method in addition to the
File.prototype.placeholder() method which became deprecated but remains supported.
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.
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
sjs-3 engine, we also had a variable named
app is deprecated, you should use
source instead. Again, both variables will live on, this is not a breaking change.
Instead of using a file named
.Trust for storing Content-Security-Policy rules, we will from now on use a file named
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
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.
The following changes did not affect the current version of any website in the Boomla Cloud, but I’m documenting them anyway for reference:
sjs-2 engine was removed,
.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.
Here are some helper scripts to help your migration if you decide to upgrade your website to use the new terminology: