8.4.4 URI resolving

At various locations in the template language, you can specifies URI's, such as for include and import, inherit, variable and insert.

These URI's can either be absolute or relative. Relative URI's will be resolved against the URI of the template that contains them. So if you define, for example, a macro in one template and call it from another template, any relative URI's within that macro will be resolved against the URI of the template containing the macro, not the one making the macro call.

In general URI's are resolved at runtime rather than at compile-time, so you can specify URI's using expressions, allthough this depends on the specific template instruction.

This section contains an explication of how the resolving of the URI's works. Most template users will not have to worry about this, since it should work as you expect.

At a technical level, the template library defines an interface SourceResolver, the concrete implementation provided will determine how the URI resolving works.

When using the template library within Kauri through the kauri-template-service module, a Kauri-specific SourceResolver is used, which supports Kauri's special service protocol and module protocol.

The resolving of the service and module protocols depends on the module within which they are used: the module protocol fetches resources from the current module, and the service protocol addresses REST-services from the current module's service registry.

So for example, two different modules might both contain a resource at templates/layout.xml, which can be fetched using the URI module:/templates/layout.xml. Depending on the module within which this URI is used, data from a different layout.xml file will be returned.

When you execute a template within a certain module, it is most logical that all URIs contained within it are also resolved within the context of that module.

However, imagine the following scenario:

• a template in a module A includes a template from module B, via the service protocol
• the template from module B includes, using a "module:" URI, another template from module B

This would not work if we evaluate this second include within the context of module A (where the template is being executed). Therefore, we have made it such that, when including templates via the service protocol, and the service protocol addresses a service from another module, the source resolving of URIs in that included template will be done within the context of that other module.

This of course works any number of includes deep. However, it only works if the template engine can be aware of the "module switch". Thus if you write a restservice which in itself retrieves data from a restservice in another module, then the template engine won't be aware of the switch. But that is a rare case, which can be worked around by using a template with an include instead.