Filtered Template Tags

RIFE2 supports a collection of specifically named template value and block tags that can be used to integrate with various features of the framework, called filtered tags. These tags will be detected when a template is parsed and they will be compiled into the template's byte code, having a negligible runtime performance impact.

The filtered value tags will only be set when you have not provided a value for them yourself, still offering full templating flexibility.

Web engine filtered tags

These are the filtered value tags that are supported by the RIFE2 web engine:

<!--v webapp:rootUrl/-->            // the root URL of your web app deployment
<!--v server:rootUrl/-->            // the root URL of your servlet container
<!--v config:[name]/-->             // value of config parameter [name]
<!--v context:pathInfo/-->          // the path info of the request
<!--v context:paramRandom/-->       // a random query parameter for the deployment
<!--v context:paramContId/-->       // query parameter with active continuation ID
<!--v context:contId/-->            // value of active continuation ID
<!--v cookie:[name]/-->             // value of request cookie [name]
<!--v param:[name]/-->              // value of parameter [name]
<!--v property:[name]/-->           // value of hierarchical property [name]
<!--v attribute:[name]/-->          // string value of request attribute [name]
<!--v route:[field path]/-->        // URL towards route stored in a router field
<!--v route:action:[field path]/--> // form action towards route from field
<!--v route:inputs:[field path]/--> // form hidden inputs towards route from field
<!--v render:[classname]/-->        // the full class name of a ValueRenderer

The tag context:paramRandom

Each time your web application is deployed, RIFE2 will generate a random number for that deployment. This can be useful to force caches to refresh stylesheet or javascript files for your application.

For example, consider the following style sheet link:

<link rel="stylesheet" href="{{v webapp:rootUrl/}}css/style.css?{{v context:paramRandom/}}">

It first uses the webapp:rootUrl filtered value to ensure that the link is always correct, regardless where the deployment is done or which route is serving the request. Then it uses context:paramRandom which will add a query parameter in the format rnd=[number]. Each time your application deploys, [number] will change and your style sheet will reload, even if browsers have already cached it.

The tag route:[field path]

You've already encountered the route: filtered value tag previously.

When the [field path] is empty, it will generate the URL towards the currently active route. This makes it very convenient to for instance specify HTML form action URLs.

The [field path] will look up the router of your active route and traverse the public fields to look for a route that matches. This allows you to even go into router fields that are part of a group.

A field hierarchy can be expressed by separating the name with a dot ., just like a regular Java field hierarchy. In order to be able to refer to any field in your router hierarchy, even from within groups, the field path supports the following additional syntax:

routerField               // relative path, starting at current router
.siteField                // absolute path, starting at your main site
.topLevel.group.someField // absolute path, delving into two router groups
^parentField              // relative path, using a field in the parent router
^^grandParentField        // relative path, using a field two levels up
^parentRouter.routerField // relative path, using a field from a router in the parent

Any combinations of . and ^ is supported to navigate through publicly available router and route field.

The tags route:action:[field path] and route:inputs:[field path]

Both these tags operate in the same way as the route:[field path] tag, but they're intended to be used with HTML forms by splitting up the action part for the URL path and the hidden inputs part for the parameters. You should always use both these tags together, otherwise RIFE2 might not generate the transferred state correctly.

The tag render:[classname]

Sometimes you want to display content that is dynamically generated but is not dependent on the HTTP request, for instance the current date and time.

This can be achieved by implementing a ValueRenderer.

For example, consider this value renderer:

package hello;

import rife.config.RifeConfig;
import rife.template.*;
import java.util.Date;

public class DateRenderer implements ValueRenderer {
    public String render(Template template, String valueId, String differentiator) {
        return RifeConfig.tools().getDefaultShortDateFormat().format(new Date());
    }
}

Will then always display the current date when used in a template:

<!DOCTYPE html>
<html lang="en">
<body>
<!--v render:hello.DateRenderer/--><br>
</body>
</html>

Since you might want to use multiple instances of a value renderer, you can also provide a differentiator suffix. This will be provided to the ValueRenderer's render method in order to allow each instance of the renderer to be differentiated.

<!--v render:hello.DateRenderer:first/--><br>
<!--v render:hello.DateRenderer:second/--><br>

Localization filtered tags

These are the RIFE2 filtered tags for localization:

<!--v l10n:[key]/-->                // dynamic localization based of resource bundles
<!--v lang:[key]/-->                // fixed localization based on language setting
<!--b lang:[key]:[lang]--><!--/b--> // localization content for specific language

The tag l10:[key]

Java provides a standard way for localizing content through the use of resource bundles. They basically provide a list of key/value mappings where the value changes for the Locale that is used.

RIFE2 provides several ways of registering ResourceBundle instances, for instance:

• Adding them to individual template instances through
  template.addResourceBundle()
• Adding them to the global RifeConfig for all templates of a particular type:
  RifeConfig.template().setDefaultResourceBundles()

From then on, any [key] that can be found the registered resource bundles will have its l10n:[key] value tag replaced in the template.

The l10n has an additional format where you can provide the resource bundle directly in the template through l10n:[bundle path]:[key]. The ResourceBundle will be looked up through the [bundle path] and instantiated using a Locale that uses the default RIFE language obtained from RifeConfig.tools().getDefaultLanguage().

The tag lang:[key]

Sometimes you want to put localized content directly into your templates and have it be displayed depending on which language is active. This can be achieved with the lang:[key] tags.

The value tag provides the location where the localized content needs to be displayed and the block tag provided the content for an individual language. RIFE2 will automatically assign the block to the value by using the language that was set in the template instance through the template.setLanguage() method. If no language is set, RifeConfig.tools().getDefaultLanguage() is used.

Authentication filtered tags

RIFE2 has comprehensive authentication features. When those are used, templates can automatically display content based on who is logged in and which roles they have.

These are the RIFE2 filtered tags for authentication:

<!--v auth:[id]/-->                       // display an auth block with the [id] when appropriate
<!--b auth:[id]--><!--/b-->               // display block for auth:[id] when authenticated
<!--b auth:[id]::login:[user]--><!--/b--> // display block for auth:[id] when [user] is authenticated
<!--b auth:[id]::role:[role]--><!--/b-->  // display block for auth:[id] when [role] is authenticated

The tag auth:[id]

The value tag auth:[id] provides a location in which authenticated content will be displayed. That location is identified through the [id].

The corresponding block tags will then provide content to display depending on various conditions:

These are the block tags that can be used:

• Block tag auth:[id]
  This block is displayed when any user is authenticated
• Block tag auth:[id]::login:[user]
  This block is displayed when a user is authenticated with login [user]
• Block tag auth:[id]::role:[role]
  This block is displayed when a user is authenticated with login [role]

---

Next learn about Value Renderers