Returns a SimpleNumber which contains the same value as the original variable, but uses java.lang.Type for the internal representation of the value. This is useful if a method is overloaded, or if a TemplateModel unwrapper has problem with automatically choosing the suitable java.lang.* type. Note that since version 2.3.9 the unwrapper has been improved substantially, so you will hardly ever need to use these built-ins, except for resolving ambiguity in overloaded method invocation.

This built-in evaluates a string as an FTL expression. For example "1+2"?eval returns number 3.

It is true if the variable exists (and isn't Java null) and is not ``empty'', otherwise it is false. The meaning of ``empty'' depends on the concrete case. This follows intuitive common-sense ideas. The following are empty: a string with 0 length, sequence or hash with no subvariables, a collection which has passed the last element. If the value is not a string or sequence or hash or collection, then it counts as non-empty if it's a number or a date or a boolean (e.g. 0 and false are not empty), otherwise it counts as empty. Note that when your data-model implements multiple template model interfaces you may get unexpected results. However, when in doubt you can use always use expr!?size > 0 or expr!?length > 0 instead of expr?has_content.

This buit-in is exceptional in that you can use the parentheses trick like with the default value operator. That is, you can write both product.color?has_content and (product.color)?has_content. The first doesn't handle the case when product is missing, the last does.

This built-in interprets a string as a FTL template, and returns an user-defined directive that - when applied to any block - executes the template just as if it was included at that point. Example:

	<#assign x=["a", "b", "c"]> <#assign templateSource = "<#list x as y>${y}</#list>"> <#assign inlineTemplate = templateSource?interpret> <@inlineTemplate>def</@inlineTemplate>

The output:

	abcdef

As you can see, inlineTemplate is a user-defined directive that, when executed, runs the template that was generated on-the-fly using the interpret. Further, the user-defined directive will append whatever its body is (in our case "def") to the output of the inline template.

You can also apply this built-in to a two-element sequence. In this case the first element of the sequence is the template source, and the second element is a name for the inline template. It can be useful to give an explicit name to the inline template for debugging purposes. So, you could have written:

	<#assign inlineTemplate = [templateSource, "myInlineTemplate"]?interpret>

as well in the above template. Note that giving the inline template a name has no immediate effect - it is only useful as an extra bit of information if you get an error report.

These built-ins check the type of a variable, and returns true or false depending on the type. The list of is_... built-ins:

This built-in returns the namespace (i.e. the ``gate'' hash to the namespace) associated with a macro variable. You can use it with macros only.

This is to create a variable of a certain TemplateModel implementation.

On the left side of ? you specify a string, the full-qualified class name of a TemplateModel implementation. The result is a method variable that calls the constructor, and returns the new variable.

Example:

	<#-- Creates an user-defined directive be calling the parameterless constructor of the class --> <#assign word_wrapp = "com.acmee.freemarker.WordWrapperDirective"?new()> <#-- Creates an user-defined directive be calling the constructor with one numerical argument --> <#assign word_wrapp_narrow = "com.acmee.freemarker.WordWrapperDirective"?new(40)>

For more information about how the constructor parameters are unwrapped and how overloaded constructor is chosen, read: Programmer's Guide/Miscellaneous/Bean wrapper