Templates

AppBase: Templates and Data Access

Appbase provides an abstraction and set of conventions for access to RDF data sources to make them easier to present via a scripting templates.

For information on configuring a velocity engine to render templates see Configuration.

Template environment

When a template is invoked a set of context variables will be prebound, these are:

variable	binding
$request	the servlet request object
$response	the servlet response object
$root	the root context path for the servlet
$lib	a java utility library (instance of Lib) which in turn can be extended by configuring components which are instances of LibPlugin and registering them using the plugin or plugins configuration property of the velocity renderer component
$app	the App which owns this renderer
all query parameter names	first string value to which they are bound in the request URL
all component names in app	the corresponding component; for example, if a component source (an instance of WSource) is defined in the configuration file then $source will be bound in the velocity environment so that calls like $source.select and $source.search can be used.

Prefix handling

One of the pains of writing templates for RDF UIs is handling URIs and prefixes. After several problems caused by models not having the prefix mappings they were expected to have I've converged on a brute force approach to prefix handling ...

Each app has a single PrefixService defined which provides prefix mapping. That mapping is used:

• to expand property/resource curies in templates
• to expand SPARQL queries with relevant prefix declarations
• to provide short id references for names in the data (cube) API (TBD)
• to define a JSONLD context for JSONLD rendering (TBD)

To configure such a service include something like the following in your configuration file:

prefixes             = com.epimorphics.appbase.core.PrefixService
prefixes.prefixFile  = {webapp}/WEB-INF/prefixes.ttl

There is a built-in default set of prefixes which will be used instead if no such PrefixService is explicitly defined. If a PrefixService is defined then these default prefixes will be added to its values. The defaults are:

@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl:   <http://www.w3.org/2002/07/owl#> .
@prefix xsd:   <http://www.w3.org/2001/XMLSchema#> .
@prefix dct:   <http://purl.org/dc/terms/> .
@prefix skos:  <http://www.w3.org/2004/02/skos/core#> .
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .
@prefix jtext: <http://jena.apache.org/text#>

This gives a predictable prefix environment which the appbase internals can rely on.

Data access

To access RDF data from the templates then use either Wrapped sources or Resource views.

Lib

The facilities provided by the library object are:

Method	Explanation
escapeHtml(string[,limit])	Escape a string for embedded HTML characters, optionally limiting it to a maximum character count
regex(string,regex)	If the regex matches returns an array of all the capture group values, otherwise null
pathEncode(string)	Encode a string so it can be safely send as a query parameter or URL path parameter. Uses just %-encoding.
pathDecode(string)	Reverse the pathEncode encoding (not normally needed because query/path parameters will be decoded on reception by the web app container

There are other methods currently lying around on Lib that may be removed or improved in the future.

In addition if a LibPlugin component is configured then it can be accessed through the library. For example, the configuration:

myplugin = com.epimorphics.appbase.webapi.ExampleLibPlugin

velocity = com.epimorphics.appbase.templates.VelocityRender
# Other velocity configuration goes here
velocity.plugin = $myplugin

Will mean that the velocity context variable $lib.myplugin refers to an instance of ExampleLibPlugin.