Template queries - BloomReach Experience - Open Source CMS

This article covers a Hippo CMS version 10. There's an updated version available that covers our most recent release.

14-02-2019

Template queries

Introduction

Template queries are used to find available templates to create new documents and folders with. They also specify substitution patterns to use during the copying of the template to the new document or folder. You can find the available template queries at /hippo:configuration/hippo:queries/hippo:templates.

Hippo CMS ships with a few standard general purpose template queries you can use to create documents and folders with, but also allows you to specify custom templates.

The hippostd:foldertype property

Content folders (i.e. nodes of type hippostd:folder) in Hippo CMS contain a property hippostd:foldertype that controls what documents and folders are allowed to be created in that folder. This multi-valued property contains the names of the template queries that are used to find available document and folder templates to create new documents and folders with. When you access the context menu of a folder in the CMS this is the property that is used to populate the available options to create documents and folders. Each template query is represented by an option in the menu. For instance Add new translated folder... or  Add new document... When you select one of these options in the menu you are presented with a dialog with either two or three input fields depending on the query: two text input fields for specifying the name of the new folder or document and their name in the url, and an optional drop down input field that lists the available types if the template query resulted in multiple templates.

The hippostd:modify property

hippostd:templatequery type inherits from the built-in JCR node type nt:query and as such contains two properties that represents the query:

[nt:query] > nt:base
  - jcr:statement (string)
  - jcr:language (string) 

where the first property contains the query statement and the second the query language in which the statement is written (xpath, sql, JCR-SQL2, or JCR-JQOM). It also contains the multi-valued property hippostd:modify that contains relative paths to properties of the template nodes with the values to be substituted when copying the template to the new document or folder during creation. The special _name pseudo property allows to modify the name of the node.

The values of the hippostd:modify property alternate between the path to the property to be changed and the value to change it with. The paths are relative to the root of the template selected by the query and can contain the special wildcard path element matcher _node that matches any node. The following table specifies the special substitution values available.

$name The name specified in the create document/folder dialog.
$holder The id of the current user.
$now Current date-time specified in the format yyyy-MM-dd'T'HH:mm:ss.SSSZ
$inherited The value of the property is copied from the parent node.
$uuid A newly created UUID.

Optional math functions may be used along with the $now option, time units supported include:

  • Y for year
  • M for month
  • D for day
  • H for hour
  • MIN for minute
  • SEC for second
  • MIL for millisecond

Here are some example usages:

  • $now/H: Round to the start of the current hour
  • $now/D: Round to the start of the current day
  • $now+2Y: Exactly two years in the future from now
  • $now-1D: Exactly 1 day prior to now
  • $now+6M+3D/D: 6 months and 3 days in the future from now, rounded down to nearest day

A script for checking the hippostd:modify paths

In the past there have been some problems with the resolution of the relative paths of the  hippostd:modify property. Bugs prevented it from working correctly in all cases. You may have inadvertently been working around these bugs by specifying illogical paths. Since release 7.9.8 (hippo-repository 2.26.13) these issues have been straightened out. But when you upgrade to this version or beyond your paths may need adjusting. For instance paths like ./_name/<subpath> used to work because _name was used as a node matcher. Now that _name is interpreted as a pseudo property such paths no longer are valid. You can use the wildcard matcher _node instead: ./_node/<subpath> or simply use the real name of the node. To find the paths that may need adjustment run the groovy script in the update editor interface called StdModifyPropertyCheck. Warnings will be logged in the script output window when it finds paths that may be incorrect. You should then manually inspect and validate them.

Did you find this page helpful?
How could this documentation serve you better?
On this page
    Did you find this page helpful?
    How could this documentation serve you better?