In package com.mitchellbosecke.pebble.loader
public interface interface Loader<T>
Interface used to find templates for Pebble. Different implementations can use different techniques for finding templates such as looking on the classpath, looking in a database, using a servlet context, etc.
public Reader getReader(T cacheKey)
The reader which will be used by Pebble to read the contents of the template.
the cache key to use to load create the reader.
public void setCharset(String charset)
A method for end users to change the charset used by the loader.
Character set used by the loader when building a reader object
public void setPrefix(String prefix)
Optional prefix to help find templates, ex "/WEB-INF/templates/" or "database_schema."
Prefix to help find templates
public void setSuffix(String suffix)
Optional suffix to help find templates, ex ".html", ".peb"
Suffix to attach to template names
public String resolveRelativePath(String relativePath, String anchorPath)
Resolves the given relativePath based on the given anchorPath.
A path is considered as relative when it starts either with '..' or '.' and followed either by a '/' or '\\' otherwise the assumption is that the provided path is an absolute path.
the relative path which should be resolved.
the anchor path based on which the relative path should be resolved on.
public T createCacheKey(String templateName)
The resolve method can eventually add information to the cache key from the context (e.g. user session information, servlet request etc.).
As a concrete example if the loader loads a template created by a user form the database the template name itself is not uniquely identify the template. The identification of the template requires also the user which created the template. Hence for the key the user id and the template name should be used. So the cache key is enhanced by some contextual information.
The implementor of the method can add as many additional contextual information to the returned object. However the following things needs to be considered:
- This method will be called on each PebbleEngine . Hence the implementation needs to be fast and eventually use some caching for the lookup process.
- The returned object is used within a cache and hence needs to implement and .
- The object is kept in memory and hence it should not be to memory heavy.
Depending on this implementation the PebbleEngine should be tuned in a way it can operate optimal. E.g. when the number of potential templates is infinite the cache should evict some templates at some point in time otherwise the stability of the memory is not given anymore.
The name of the template
public boolean resourceExists(String templateName)