Description

Motivation

At the moment, sorting navigation or Live Data entries by title can be surprising as this uses the raw title, which might be different from the displayed title when a sheet is used. The same applies to filtering in Live Data, where filtering by title might not work as expected in these cases. Further, displaying lots of titles is slow as for every title, the full document needs to be loaded, and the title needs to be evaluated.

Idea

The main idea is to just store a computed title in the database in a separate column. This title should be evaluated without the context of the current request, possibly even with a different user in context, similar to the indexing user we use for indexing the computed title in Solr search. The stored title would be used in all places but for the title of the current page. These places include in particular:

• Navigation trees
• Live Data tables
• Links where we display the title of the page
• Page pickers

We still dynamically evaluate the title of the current page and use this dynamically evaluated title as the title displayed at the top of the page, the browser's title bar and other places where we display the title of the current page (but not necessarily in navigation trees). Thereby, we allow applications to adjust the title based on URL parameters, to show the user for example that a certain section is displayed, the tag page of a certain tag is displayed, …

This is an alternative to the Title Cache idea. In contrast to the title cache, the choice here is to just store all titles, dynamic or not. The motivation behind this is that there are a lot of "dynamic" titles, in particular when sheets are used, that, in fact, only depend on the content of the page and the sheet and thus never change unless one of these documents change. In fact, it seems hard to imagine use cases where you would want a title in a navigation tree or Live Data that depends on anything but the document and the sheet. We already made a very similar choice for storing computed titles in Solr search so it seems logical to do the same in the database.

Impact

The main advantages would be:

• Sorting and filtering uses the actually displayed title, no more computed titles that cannot be properly sorted and filtered
• Much faster displaying of titles, allowing faster loading of navigation trees for example
• Allows more efficient caching of database requests (the request for the main navigation tree could be cached, for example, so only rights would need to be checked on the cached result)

Possible disadvantages:

• Less dynamic titles, titles containing the current date wouldn't work anymore for example
• The computed title could reveal potentially private information (but it seems unlikely that a computed title would contain information that is not already present in one of the other properties of the page). What we need to ensure is that a user cannot add a document sheet binding with a sheet that the user cannot access, as this would reveal the title of that sheet.

Implementation

A new column should be added to the documents table to store the computed title. The computed title would need to be computed and stored whenever the page is saved. Further, there are some cases for which we would need a background job to compute and update all affected pages:

• A sheet is updated - re-compute all titles of all documents using that sheet (either via a direct document sheet binding or via a class sheet binding)
• When a class sheet binding is added, updated, or removed, all titles of all documents with XObjects of that class need to be re-computed

Further, we need to implement a protection against revealing titles of pages that the current user cannot access. This could be done in two ways:

• Use a safe user context with guest or a designated user for computing the titles
• Add a listener to prevent adding a sheet binding to a document the author cannot access