@page title="Settings" keywords="settings, options, engine"> <@sect title="Things you must know about settings">
The basic definition of the "setting" term is <@a href="overview.html#settings">here...@a> <@sect title="The common characteristics of settings">
The characteristics of a setting can be described with these attributes:
Notes:
Setting values can be specified in multiple layers. For example, it is possible that a setting is specified in the configuration file, and then again with a command-line argument of the command-line tool.
Setting layers has a priority order, for example, the setting layer defined by the command-line arguments has higher priority than the setting layer defined by the configuration file. When the value of the same setting is specified in two layers, then the value that comes from the layer with higher priority overrides the setting value comes from the lower layer. If the type of the setting is not map or sequence, then this simply means that the value from the higher layer will be used, and the other value will be totally hidden. But if the setting type is sequence or hash, then the sequence values will be merged:
When sequences are merged, the two sequences are concatenated, and the sequence with the higher priority will start the new concatenated sequence.
When hashes are merged, the union of the two hashes is constructed, and for clashing keys the values in the hash with higher priority will be used. The type of the value of the hash items is not considered when the merging happens, simply the item from the higher priority hash will be used in the resulting hash. Thus, hash merging is not "deep", becasue the value of clashing items with hash values are not merged. For example, if you merge <@c>{x:{v:1}, y:2}@c> with <@c>{x:{w:2}}@c>, then the result will be <@c>{x:{w:2}, y:2}@c>, and not <@c>{x:{v:1, w:2}, y:2}@c>.
Logically, the rules described in this section can be applied for more than two layers of settings as well.
@sect> @sect> <@sect title="Directories"> <@setting name="sourceRoot" type="string (path)" default="" merging=false clShort="S" antAltAtt="srcdir" /> <@setting name="outputRoot" type="string (path)" default="" merging=false clShort="O" antAltAtt="destdir" /> <@setting name="dataRoot" type="string (path)" default="ex:the value of <@s\gsourceRoot@s\g" merging=false /> <@setting name="alwaysCreateDirectories" type="boolean" default="false" merging=false antAltAtt="alwaysCreateDirs" />In the typical use case FMPP processes all files in the directory specified by <@s>sourceRoot@s>, and writes the result into the directory specified by the <@s>outputRoot@s> directory. These two root directories serve as the root directory of two virtual file systems that store the source files and the output files respectively. This means that all files that FMPP processes must be inside the source root directory (except data files - see later), and it is guaranteed that all output files will be inside the output root directory (as far as you do not by-pass FMPP intentionally with custom extensions). You can't leave the roots by moving upward with <@c>..@>-s. Also, when you refer to files or directories in the templates as the parameters of predefined directives, absolute paths like <@c>/example.html@c> are interpreted relatively to the source or output root directories (except if the parameter deals with data files - see later).
Note that both the source root and the output root must be defined before starting a processing session (but a front-end may assings a default value to them). Also, if you use the <@s>outputFile@s> setting these two settings always have a default value.
The directory specified by <@s>dataRoot@s> is interesting for <@a href="dataloader.html">data loaders@a> only. If a data loader gets a relative path, then it should interpret that relatively to the data root directory. If it gets an absolute path, it should interpret that as is. As you can see from this, data root directory does not try to mimic a file system root as the other two root directories. Data loaders can reach files outside the data root directory.
By default, the data root is the same as the source root. This encourages the practice where you store the data files in the, say, <@c>data@> subdirectory of the source root, and then mark that directory with a <@c>ignoredir.fmpp@> file (file content is irrelevant), so FMPP will not process the content of the directory. Thus, you keep all input together: data sources, templates and static files (as images).
By default, no empty subdirectories will be created in the output root directory. More precisely, directories are created only on demand, when actual output files have to be created in them, hence normally you don't have empty directories in the output. However, this behavior can be changed with <@c>alwaysCreateDirectories@c>; with that setting set to <@c>true@c>, each source directory will produce a corresponding output directory (unless it contains an <@c>ignoredir.fmpp@> file). Also, if a source directory contains a file named <@c>createdir.fmpp@c> (file content is irrelevant) then the corresponding output directory will be created, regardless of the <@c>alwaysCreateDirectories@c> setting (unless, again, <@c>ignoredir.fmpp@> is also present)
It is possible to tell FMPP to process only certain files and directories of the source root, not all of them; see the <@s>sources@s> setting.
@sect> <@sect title="Source and output files"> <@setting name="sources" type="sequence (of paths)" default="" merging=true /> <@setting name="outputFile" type="string (path)" default="" clShort="o" merging=false />
Be default FMPP processes all files in the source root directory. But if you use the <@s>sources@s> setting, FMPP will process only the files and/or directories listed there. Relative paths in this setting are resolved relatively to the source root directory, not to the configuration base (unless you use <@s>outputFile@s> setting).
If you use the <@s>outputFile@s> setting, then FMPP switches to single file mode. In this mode, it will process only 1 files, and store its output in the file specified by the <@s>outputFile@s> setting. You must use <@s>sources@s>, and it must list exactly 1 file. If a relative path is given in the <@s>sources@s>, it is resolved relatively to configuration base, not to the source root. If you didn't specified <@s>outputRoot@s> or <@s>sourceRoot@s>, it will default to the parent directory of the output file or source file respectively.
The user interface of front-ends tend to require you to use some special way to specify the value <@s>sources@s> setting. Please read the <@a href="frontends.html">documentation of the front-end@a> you use about this. Note that configuration files are front-end independent, so there you always simply set <@s>sources@s> be assigning value to the <@c>sources@c> key.
@sect> <@sect title="Text encoding issues"> <@setting name="sourceEncoding" type="string" default="ISO-8859-1" clShort="E" merging=false /> <@setting name="outputEncoding" type="string" default="source" merging=false /> <@setting name="urlEscapingCharset" type="string" default="output" merging=false />People use different encodings to store text in binary form, often referred as charsets. Examples of charsets are: <@c>ISO-8859-1@c>, <@c>ISO-8859-2@c>, <@c>CP852@c>, <@c>CP1250@c>, <@c>Shift_JIS@c>, <@c>UTF-8@c>. FMPP internally uses UNICODE everywhere, but when it has to read a text file or write a text file, it must deal with charsets to correctly decode/encode the text. To read text files, FMPP uses the source encoding. This is be default ISO-8859-1. Also, a FreeMarker template has the ability to tell its own encoding with <@c><#ftl encoding="<@r>something@>">@>, and this overrides the source encoding for the individual template file.
To write text files, FMPP uses the output encoding. This is be default holds the special value <@c>source@>, which means that FMPP will use the encoding of the source text file (template file). If you change the value of the setting to a concrete charset, such as UTF-8, then text files will be always written with that encoding. However, templates can set the encoding of the output file with <@c><@pp.setOutputEncoding encoding="<@r>something@>"/>@>, and this overrides the encoding dictated by the settings.
The <@s>urlEscapingCharset@s> specifes the name of the charset (encoding) used for URL escaping. It defaults to <@c>output@c>, which means that the output encoding will be used for URL escaping. URL escaping happens for example when you use FreeMarker's <@c>url@c> built-in (e.g. <@c><a href="foo.cgi?id=<#noparse>${id?url}#noparse>">@c>) or the <@a href="pphash.html#key_urlPathEnc"><@c>pp.urlPathEnc@c> method@a>.
All of these settings understands the special charset <@c>host@c>, which means the default encoding of the host operating system.
The set of supported charsets (and their preciese names) depends on the Java platfrom implementation you run FMPP on.
@sect> <@sect title="Processing mode choosing" anchor="processingMode"> <@setting name="modes" type="sequence (of function calls)" default="ex:empty" clShort="M" merging=true /> <@setting name="ignoreCvsFiles" type="boolean" default="true" merging=false /> <@setting name="ignoreSvnFiles" type="boolean" default="true" merging=false /> <@setting name="ignoreTemporaryFiles" type="boolean" default="true" merging=false />When FMPP has to process a file, it has to decide how to process that. That is, it has to choose a "processing mode" for the file. The processing mode can be one of:
First, if the <@s>ignoreCvsFiles@s> setting is true, and the file name is <@c>.cvsignore@c> or matches <@c>.#?*@c>, or the file is inside a sub-directory of the source root that is called <@c>CVS@c>, then it chooses the "ignore" processing mode. Also, if the <@s>ignoreSvnFiles@s> setting is true, and the file is inside a sub-directory of the source root that is called <@c>.svn@c>, then it chooses the "ignore" processing mode (note that it doesn't ignore conflict files, i.e., <@c>*.mine@c> and <@c>*.r<@r>number@r>@c>). Also, if <@s>ignoreTemporaryFiles@s> setting is true, and the file name matches <@c>?*~@c> or <@c>~?*@c> or <@c>#?*#@c> or <@c>%?*%@c> or <@c>_.?*@c>, or the extension (the part after the last dot in the file name) after converting to lowercase matches <@c>bak@c> or <@c>~*@c> or <@c>*~@c> then it chooses the "ignore" processing mode. Note that the FMPP Ant task always sets these settings to <@c>false@c>, so it does not interfere with the <@c>defaultExcludes@c> parameter of Ant.
Then, the processing mode is chosen with a sequence of <@a href="pathpattern.html">path patterns@>, which is defined by the <@s>modes@s> setting. The first path pattern in the sequence that matches the <@a href="overview.html#virtualPath">virtual path@a> of the file, chooses the processing mode. If no matching path were found, then FMPP chooses the processing mode automatically:
The <@s>modes@s> setting is a list of TDD functions, where the function name is either <@c>execute@>, <@c>copy@>, <@c>renderXml@c>, or <@c>ignore@>. The arguments to the functions are one or more path patterns of virtual paths in the source file system. For example this (in a configuration file):
<@prg> modes: [ ignore(**/tmp/) copy(foo/**/*.html, foo/**/*.htm) execute(**/*.html, **/*.htm, **/*.xhtml) copy(**/*) ] @prg>will produce this processing mode chooser sequence:
Path pattern | Processing mode |
---|---|
<@c>**/tmp/@> | ignore |
<@c>foo/**/*.html@> | copy |
<@c>foo/**/*.htm@> | copy |
<@c>**/*.html@> | execute |
<@c>**/*.htm@> | execute |
<@c>**/*.xhtml@> | execute |
<@c>**/*@> | copy |
Note that processing modes are only applicable to files, not to directories. Say, you can't tell FMPP to ignore a directory, but to ignore all files in the directory (as <@c>**/tmp/@c> above). The end result will be that the directory will not be created, as it contains no output file.
@sect> <@sect title="Header and footer choosing"> <@setting name="borders" type="sequence (of function calls)" default="ex:empty" merging=true />With these settings you can insert a header before templates, and insert a footer after templates (templates = files processed in "execute" processing mode). The insertion of header and footer happens only in the memory of the computer, and does not modify the source files. This can be used to add common headers and footers to the templates without actually typing them again and again. Also, you can change the header/footer of many templates at once.
The intent of headers and footers is not to show something at the top and bottom of pages. Rather it is to insert FTL directives that import or include commonly used macros, or to place the page inside a block, as <@c><@myLayout><@r>...@r></myLayout>@c>. For concrete examples please see <@example 'border' />.
<@note>Unfortunately the inserted header displace the error locations (column, row) in the error messages (I can't fix it in FMPP; FreeMarker improvements are needed to address this). However, if the header doesn't contain line-break, then this unwanted effect is limited to the first line of the template. So it's strongly recommended to not use line-break in headers.@note>Footers and headers are chosen with similar mechanism to processing modes (see <@s>modes@s>). There are two independent sequence of path-pattern to text entry mappings (so called "choosers"), one for choosing headers, and one for choosing footers. When FMPP loads a template file, it checks if the <@a href="overview.html#virtualPath">virtual path@a> of the file matches to an entry in the header chooser sequence, and if so, it uses the header specified in the first such entry. Also, it does the same with the sequence of footers choosers, to choose a footer.
There is a single setting to build both sequences at once: <@s>borders@s>. You give a sequence of <@c>header@>, <@c> footer@> and <@c>border@> functions in it. The first argument to <@c>header@> and <@c> footer@> functions is the text of header and footer respectively, and the further arguments are the path patterns of virtual paths in the source file system. If you omit the path patterns, that's the same as if you give <@c>**@c> (i.e. match all files). <@c>border@> is convenience function: <@c>border(<@r>a@>, <@r>b@>, <@r>paths...@>)@> is equivalent with <@c>header(<@r>a@>, <@r>paths...@>), footer(<@r>b@>, <@r>paths...@>)@>. Example:
<@prg><#noparse> header("<#import '/lib/css.ftl' as css>", **/*.css) border("<#import '/lib/page.ftl' as p><@p.myLayout>", "@p.myLayout>", **/*.html, **/*.htm) #noparse>@prg>This build these sequences:
Path pattern | Header |
---|---|
<@c>**/*.css@> | <@c><#import '/lib/css.ftl' as c>@> |
<@c>**/*.html@> | <@c><#import '/lib/page.ftl' as p><@p.myLayout>@> |
<@c>**/*.htm@> | <@c><#import '/lib/page.ftl' as p><@p.myLayout>@> |
Path pattern | Footer |
---|---|
<@c>**/*.html@> | <@c></@p.myLayout>@> |
<@c>**/*.htm@> | <@c></@p.myLayout>@> |
Only the first matching entry of the sequence is used for a file, the later entries are ignored. But sometimes you want to choose multiple headers/footers for the same file. In that case, you can define multiple independent sequences, so said, layers. Layers are separated with <@c>layer()@c>. For example, modify the above example, so it imports <@c>/lib/common.ftl@c> at the top for all files, without disabling the other headers/footers:
<@prg><#noparse> # The 1st (implicit) layer starts here header("<#import '/lib/common.ftl' as c>", **/*.css, **/*.html, **/*.htm), layer() # The 2nd layer starts here header("<#import '/lib/css.ftl' as css>", **/*.css), border("<#import '/lib/page.ftl' as p><@p.myLayout>", "@p.myLayout>", **/*.html, **/*.htm) #noparse>@prg>Here we have two independent header chooser sequences, so both CSS and HTLM files will import <@c>lib/common.ftl@c>, and additionally CSS files will import <@c>lib/css.ftl@c>, and HTML files will import <@c>lib/page.ftl@c> have the <@c>@p.myLayout@> block. You can have any number of layers.
A header chosen from an earlier layer will be used earlier in the template file than headers chosen from later layers. A footer chosen from an earlier layer will be used later in the template file than footers chosen from later layers. For example:
<@prg> borders: [ border('L1(', ')L1') layer() border('L2{', '}L2') layer() border('L3[', ']L3') ] @prg>If the content of a template file is <@c>content@c>, its output will be:
<@prg> L1(L2{L3[content]L3}L2)L1 @prg> @sect> <@sect title="Output file name deduction"> <@setting name="removeExtensions" type="sequence (of strings)" default="ex:empty" clShort="R" merging=true /> <@setting name="removePostfixes" type="sequence (of strings)" default="ex:empty" merging=true /> <@setting name="replaceExtensions" type="sequence (of strings)" default="ex:empty" merging=true /> <@setting name="removeFreemarkerExtensions" type="boolean" default={'0.9.15': 'false', '0.9.15': 'true'} merging=false since='0.9.16' />Initially the name of the output file is the same as the name of the source file. These settings allow you to change the output filename somewhat, by removing and replacing parts of it.
The precise meaning of the settings:
These settings are applied in the order as they are listed above. Each setting is applied only once on the same file name.
Note that output file name deduction only applies to files, not to directories.
@sect> <@sect title="Skipping unchanged files"> <@setting name="skipUnchanged" type='string' default="none" clShort="-U" merging=false />This setting specifies that the processing of which source files can be skipped, if the source file was not modified after the last modification time of the output file. The value of setting can be one of:
If the output does not exist, the source file will be always processed.
This feature will not work for templates that rename or drop the original output file during the template execution, because in the next processing session FMPP will believe that the output files for those files are missing, and thus it will process them again.
@sect> <@sect title="Turn choosing"> <@setting name="turns" type="sequence (of function calls)" default="ex:empty sequence" merging=true />When FMPP has to process multiple files in the same processing session (for example, when you process a whole directory), then the order in which the files will be processed, is undefined. This is a problem in certain use cases, where it must be ensured that certain files will be processed later than others. For example, if a page contains the alphabetic index of keywords occur in other pages, then that page must be processed for the last, because the information is collected during the processing of the other pages. This is what turns are about: to guarantee the order of the processing of files.
The processing session is divided up into, so called, turns. Turns are identified with the turn number, which is simply the order of the turn. The session starts with turn 1, then comes turn 2, and then comes turn 3, etc. FMPP puts all files that will be processed into exactly one of the turns, based on the turn chooser sequence.
The turn chooser sequence is a sequence of path-pattern -> turn-number pairs. For each source file, the <@a href="overview.html#virtualPath">virtual path@a> of the source file is compared with these <@a href="pathpattern.html">path patterns@a>, and the first pattern of the sequence that matches determines the turn in which the file will be processed. If there is no matching pattern in the sequence for the file, then the file will be processed in turn 1.
For example, if <@c>config.fmpp@c> contains this line: <@prg> turns: [turn(3, main_idx.html), turn(2, **/*_idx.html)] @prg>
then all files where the file name ends with <@c>_idx.html@c> will be processed in turn 2, except <@c>main_idx.html@c>, which will be processed in turn 3. All other files will be processed in turn 1.
There is no upper limit of the turn number (except a technically limit, somewhere near 2 thousand million). Simply, the last turn will be the turn with the highest number, which is mentioned in the turn chooser sequence, or 1, if the sequence is empty. The first turn is always the turn 1. It is not a problem if a turn contains no file processing.
See <@example 'session' /> for a working example, or the FMPP task call in the <@c>build.xml@c>.
@sect> <@sect title="Data model building" anchor="data"> <@setting name="data" type="hash" default="" clShort="D" merging=true /> <@setting name="localData" type="sequence" default=""merging=true /> <@setting name="templateData" type="string (Java class name)" default="" merging=false deprecated="Use <@s\glocalData@s\g instead." />As you may <@fma href="dgui_quickstart_basics.html">know from the FreeMarker manual@fma>, FreeMarker generates the output by merging a template with a data model, and the data model is a hash variable, the root hash. With FMPP terminology, it is usually just referred as "the data". In FMPP, the population of the root hash happens in two places:
From the view point of FreeMarker templates, variables that are part of the session level data and the part of the local data are not different. They are equal parts of the data model.
<@sect title="ex:More about the <@s\gdata@s\g setting">When you use <@a href="tdd.html">TDD syntax@a> for defining the hash for <@s>data@s>, TDD function calls are interpreted as <@a href="dataloader.html">data loader@a> invocations. For reminder, here is the relevant part of <@c>config.fmpp@c> from <@example path="qtour_step4" />:
<@prg> data: { tdd(data/style.tdd) birds: csv(data/birds.csv) } @prg>TDD syntax makes it possible to enter values directly as well, without using data loaders. For example, you could directly enter the "birds" table with TDD (altoguh it is not too convenient): <@prg> data: { tdd(data/style.tdd) birds: [ { name: arctic-tern description: "Flies very long distances all years." favoriteFood: sardine } { name: house-sparrow description: "Don't you say you don't know it..." favoriteFood: sunflower } { name: sakeret description: "Great hunter of the sky." favoriteFood: pigeon } ] }@prg> @sect> <#-- more about data --> <@sect title="ex:More about the <@s\glocalData@s\g setting" anchor="localData">
Let's start with a simple example. We have a variable <@c>bgColor@c> in the session level data with value <@c>green@c>. We want to override this with value <@c>yellow@c> for the source files that are in directory <@c>sub@c> (or in its subdirectories, ...etc.):
<@prg> data: { bgColor: green } localData: [ case(sub/**, {bgColor: yellow}) ] @prg>Complicate it a bit... now set the <@c>bgColor@c> if the file is in directory <@c>sub@c> or <@c>sub2@c>:
<@prg> localData: [ case(sub/**, sub2/**, {bgColor: yellow}) ] @prg>Now do the same as earlier, except for files that are in directory <@c>sub/sky@c>, where the <@c>bgColor@c> is always <@c>blue@c>:
<@prg> localData: [ case(sub/sky/**, {bgColor: blue}) case(sub/**, sub2/**, {bgColor: yellow}) ] @prg>The rule is that the first <@c>case(<@r>...@r>)@c> where one of the path patterns matches the source file path will specify the local data (specified as the last argument), and the further <@c>case(<@r>...@r>)@c>-s are ignored. There can be any number of <@c>case(<@r>...@r>)@c>-s listed (note that <@c>localData@c> is a sequence), and a <@c>case(<@r>...@r>)@c> can have any number of path patterns (but 0).
Tricky example: do the same as earlier, but don't override the color if the file name starts with <@c>foo@c>:
<@prg> localData: [ case(**/foo*, {}) case(sub/sky/**, {bgColor: blue}) case(sub/**, sub2/**, {bgColor: yellow}) ] @prg>Assume that you want to set variable <@c>author@c> to <@c>Joe@c> for all files where the file name contains <@c>_j.@c>, and to <@c>Amy@c> for all files contains <@c>_a.@c>. But, you want to do this independently of setting <@c>bgColor@c>. In this case you have to use layers:
<@prg> localData: [ # The 1st (implicit) layer starts here case(**/foo*, {}) case(sub/sky/**, {bgColor: blue}) case(sub/**, sub2/**, {bgColor: yellow}) layer() # The 2nd layer starts here case(**/*_j.*, {author: Joe}) case(**/*_a.*, {author: Amy}) ] @prg>The rule is that layers are separated with a <@c>layer()@c> function call. You can have any number of layers. The <@c>case(<@r>...@r>)@c>-list of each layer will be searched for the first match independently. If more layers put the same variable into the data model, the higher layer (earlier layer) wins (hence "layers"). Layers are calculated starting with the lowest layer. Empty layers are allowed (can be practical when you are using setting merging).
The last parameter of the case can be:
Here's an example of using of the <@c>bsh@c> function: It will execute a BeanShell script file for each HTML to add local data. For example, the script file for source file <@c>foo/bar.html@c> should be <@c>foo/bar.html.bsh@c>. If there is no script for the HTML file, it will not consider that as an error.
<@prg> modes: ignore(**/*.bsh) localData: [ case(**/*.htm, **/*.html, bsh({ignoreMissing})) ] @prg>A possible <@c>.bsh@c> file, that adds local variables <@c>x@c> and <@c>y@c>:
<@prg> res = new HashMap(); res.put("x", "Just for test: " + templateEnvironment.getData("author")); res.put("y", "Blah..."); return res; @prg>For a working example see <@example 'local_data' />.
@sect> <#-- more about localData --> @sect> <@sect title="Auto-escaping"> <@setting name="outputFormat" type="string" default='"undefined"' merging=false since="0.9.16" /> <@setting name="outputFormatsByPath" type="sequence (of case function calls)" default="[]" merging=true since="0.9.16" /> <@setting name="mapCommonExtensionsToOutputFormats" type="boolean" default={'0.9.15': 'false', '0.9.16': 'true'} merging=false since="0.9.16" />Auto-escaping means that in values printed with interpolations (with <@c>${'$'}{<@r>expression@>}@>, not with <@c><@directive />@>, nor with static text), the parts that have special meaning in the output format (like <@c>&@> and <@c><@> have if the output format is HTML) are replaced with an escaped form (with <@c>&@c>, <@c><@c> in this case). What patterns will be escaped and how depends on the output format, like <@c>HTML@>, <@c>XML@>, <@c>RTF@>, etc.
Output formats and auto-escaping is a FreeMarker template language feature. See the <@fma href="dgui_misc_autoescaping.html">related section in the FreeMarker documentation@> for more details.
In FMPP, the output format of a template is decided as follows, in this order:
Example:
<@prg> outputFormat: HTML outputFormatsByPath: [ case(legacy/, undefined) case(**/*.xfoo, **/*.xbar, XML) ] @prg>With this all templates inside the <@c>legacy@> directory will have <@c>undefined@> output format, and template files that have <@c>xfoo@> or <@c>xbar@> file extension will have <@c>XML@> output format. The output format is decided by the first matching <@c>case(...)@>, so for example <@c>legacy/example.xfoo@> will have <@c>undefined@> output format, despite that it matches <@c>**/*.xfoo@>. If there's no match in <@s>outputFormatsByPath@>, and we assume for simplicity that <@s>mapCommonExtensionsToOutputFormats@> is <@c>false@>, then the output format will be <@c>HTML@> according the <@s>outputFormat@> setting.
The <@c>case@> function in <@s>outputFormatsByPath@> has 2 or more arguments. The last argument is the name of the output format. The arguments before that are the <@a href="pathpattern.html">path patterns@> that will be matched against the <@a href="overview.html#virtualPath">virtual path@a> of the template, in logical or
relation.
The valid output format names can be found in the <@fma href="dgui_misc_autoescaping.html">FreeMarker documentation@>.
The common extension used by <@s>mapCommonExtensionsToOutputFormats@> are the following (in this format: Associated output format: case-insensitive file extensions
):
Set the locale (language, country) used in templates. It has significance because different countries write numbers differently, sort text differently, etc.
The value is a string which consist of a language code (lowercase two-letter ISO-639 code) plus optional county code (uppercase two-letter ISO-3166 code) separated from the language code with underscore, and if we have specified the country then an optional variant code (not standardized) separated from the country with underscore. Examples of valid values: <@c>en@>, <@c>en_US@>, <@c>en_US_MAC@>. FreeMarker will try to use the most specific available locale, so if you specify <@c>en_US_MAC@> but that is not known, then it will try <@c>en_US@>, and then <@c>en@>, and then the default locale of the computer.
Also, the special value <@c>host@> can be used to ask FMPP to use the default locale of the host operating system. However, for most applications it is not recommended to depend on the host locale, since then the output will depend on where you run the generation (and not on what people will use the output).
If you don't know what your locale string would be, use the <@c>--print-locales@> option of the command-line tool. Note that unfortunately, the codes printed here are far the superset of locales that Sun's Java platform implementation actually correctly handles.
Note that the initial value of the setting is <@c>en_US@>, because it is the locale that formats things similarly as a programmer would expect.
@sect> <@sect title="Number format"> <@setting name="numberFormat" type="string" default="0.############" merging=false />This specifies the default format of numbers when FreeMarker has to convert numbers to strings. For example, if you change this setting to <@c>0.00@> then:
<@prg><#noparse>${1}, ${1.1}, ${1.245}#noparse>@prg>will print (if the locale setting is <@c>en_US@>):
<@prg>1.00, 1.10, 1.25@prg>Note that you can override the effect of this setting in the templates with <@c><#setting number_format="<@r>something@>">@>, also you can override this for each interpolations with <@c>?string("<@r>something@>")@c>.
The syntax and semantic of the format string is as <@c>java.text.DecimalFormat@c> defines it. For convenience I quote a part from the documentation of <@c>java.text.DecimalFormat@c>:
Pattern Syntax
pattern := pos_pattern{';' neg_pattern} pos_pattern := {prefix}number{suffix} neg_pattern := {prefix}number{suffix} number := integer{'.' fraction}{exponent} prefix := '\u0000'..'\uFFFD' - special_characters suffix := '\u0000'..'\uFFFD' - special_characters integer := min_int | '#' | '#' integer | '#' ',' integer min_int := '0' | '0' min_int | '0' ',' min_int fraction := '0'* '#'* exponent := 'E' '0' '0'* Notation: X* 0 or more instances of X { X } 0 or 1 instances of X X | Y either X or Y X..Y any character from X up to Y, inclusive S - T characters in S, except those in T
Special Pattern Characters
Many characters in a pattern are taken literally; they are matched during parsing and output unchanged during formatting. Special characters, on the other hand, stand for other characters, strings, or classes of characters. They must be quoted, unless noted otherwise, if they are to appear in the prefix or suffix as literals.
The characters listed here are used in non-localized patterns. Localized
patterns use the corresponding characters taken from this formatter's
DecimalFormatSymbols
object instead, and these characters lose
their special status. Two exceptions are the currency sign and quote, which
are not localized.
Symbol | Location | Localized? | Meaning |
---|---|---|---|
0 | Number | Y | Digit |
# | Number | Y | Digit, zero shows as absent |
. | Number | Y | Decimal separator or monetary decimal separator |
- | Number | Y | Minus sign |
, | Number | Y | Grouping separator |
E | Number | Y | Separates mantissa and exponent in scientific notation. Need not be quoted in prefix or suffix. |
; | Subpattern boundary | Y | Separates positive and negative subpatterns |
% | Prefix or suffix | Y | Multiply by 100 and show as percentage |
\u2030 | Prefix or suffix | Y | Multiply by 1000 and show as per mille |
¤ (\u00A4) | Prefix or suffix | N | Currency sign, replaced by currency symbol. If doubled, replaced by international currency symbol. If present in a pattern, the monetary decimal separator is used instead of the decimal separator. |
' | Prefix or suffix | N | Used to quote special characters in a prefix or suffix,
for example, "'#'#" formats 123 to
"#123" . To create a single quote
itself, use two in a row: "# o''clock" . |
This setting specifies how boolean values will be converted to text or from text inside FreeMarker templates (not in <@a href="dataloader.html">data loaders@a>). However, confusingly enough, when this is <@c>true,false@> (the default) then something like <@c>${'$'}{myBoolean}@c> is an error, because FreeMarker denies using <@c>"true,false"@c> for implicit boolean to text conversion. So to utilize this setting, set it to something different, like <@c>Y,N@c>, and then it will work as expected. Where you want to print <@c>true@>/<@c>false@>, write <@c>${'$'}{myBoolean?c}@c> (note the <@c>?c@>), which will always print <@c>true@>/<@c>false@>, regardless of the <@s>booleanFormat@> setting.
This setting directly correspond to the FreeMarker setting with similar name, so find the full documentation there: <@fma "ref_directive_setting.html#topic_date_format_settings">FreeMarker settings@fma>.
Example: <@c>"Yes,No"@> means that <@c>${'$'}{myBoolean}@c> will print <@c>Yes@c> or <@c>No@c>. @sect> <@sect title="Date/time format"> <@setting name="dateFormat" type="string" default="" merging=false /> <@setting name="timeFormat" type="string" default="" merging=false /> <@setting name="datetimeFormat" type="string" default="" merging=false /> <@setting name="timeZone" type="string" default="" merging=false /> <@setting name="sqlDateAndTimeTimeZone" type="string" default="" merging=false since='0.9.15' />
These settings specify how date/time/date-time values will be converted to text or from text inside FreeMarker templates (not in <@a href="dataloader.html">data loaders@a>, unless said otherwise).
These settings directly correspond to the FreeMarker settings with similar name, so find their full documentation there: <@fma "ref_directive_setting.html#topic_date_format_settings">FreeMarker settings@fma>.
Examples of <@s>datetimeFormat@s>-s: <@c>"dd.MM.yyyy HH:mm:ss"@c> (where <@c>HH@c> means 0-23 hours) or <@c>"MM/dd/yyyy hh:mm:ss a"@c> (where <@c>a@c> means AM or PM, if the current language is English), <@c>"iso"@c> (ISO 8601:2004 format), <@c>"xs"@c> (XML Schema format).
Examples of <@s>timeZone@s>-s: <@c>"GMT"@c>, <@c>"GMT+2"@c>, <@c>"GMT-1:30"@c>, <@c>"CET"@c>, <@c>"PST"@c>, <@c>"America/Los_Angeles"@c>, <@c>"JVM default"@c>
When a format setting isn't set, the default format of the current locale (country) will be used, which are specified by the Java installation you run FMPP on. If the <@s>timeZone@s> isn't set, the time zone of the host computer will be used (specified by the Operating System).
@sect> <@sect title="Handling errors"> <@setting name="stopOnError" type="boolean" default="true" clShort="s, c" merging=false />Be default when FMPP encounters problem during the processing of a source file, it terminates the whole processing session with the error. It can be annoying if you have many bad files, because you have to restart the whole session and wait until the session reaches another bungled template (or other kind of problematic source file), again and again, until you have fixed all of them. If you change this setting to <@c>false@c>, FMPP will not stop on the errors, just skips the problematic source file and continues the processing session with the next source file. You should use <@s>logFile@s> together in this case, so you can later digest all problems occured during the processing session.
Note that this settings will only suppress errors that occur during the processing of source files. It will not suppress errors like, for example, bad data files (unless it's loaded in a template with <@c>pp.data@c>) or invalid setting values.
@sect> <@sect title="Expert mode"> <@setting name="expert" type="boolean" default="false" clShort="x" merging=false />This setting is to enable suspicious situations, when the engine or the tool suspects that you have miss-configured something, and thus an accidental data loss can happen. It is recommended to leave this setting false, until it actually blocks something that you want to do.
Please note that overwriting a file in general is a normal situation for FMPP; no expert mode required to do that.
@sect> <@sect title="Case sensitive path comparison"> <@setting name="caseSensitive" type="boolean" default="false" merging=false />This setting tells if FMPP should differentiate upper- and lower-case letters when it compares paths for equality, or when it matches paths to path patterns. Regardless of this setting, FMPP always tries to keep the case of file names (i.e. the output of <@c>Foo.txt@> will be <@c>Foo.txt@>, and not <@c>foo.txt@> or <@c>FOO.TXT@>), as far as the host operating system does not prevent this.
@sect> <@sect title="Logging" anchor="logging"> <@setting name="logFile" type="string (path)" default="" clShort="L" merging=false /> <@setting name="appendLogFile" type="boolean" default="" merging=false />If these settings are supported or not, depends on the front-end you use. If a setting is not supported, the front-end must silently ignore it.
If the <@s>logFile@s> setting is set, the front-end should record information about the processing session into the file, such as the warning messages and errors occurred.
If <@s>appendLogFile@s> is <@c>false@c>, then already existing log file (possibly left from the previous processing session) is deleted and restarted. This is the recommended default behavior, however a front-end may chooses something different. If <@s>appendLogFile@s> is <@c>true@c>, then old log file should be continued.
Please read the documentation of <@a href="frontends.html">the front-end you use@a> for the precise behavior of these settings.
@sect> <@sect title="Showing the progress and other messages"> <@setting name="quiet" type="string" default="" clShort="q, v, Q" merging=false /> <@setting name="echoFormat" type="string" default="" clShort="F" merging=false /> <@setting name="columns" type="integer" default="" merging=false /> <@setting name="printStackTrace" type="boolean" default="false" merging=false /> <@setting name="snip" type="boolean" default="true" merging=false />If these settings are supported or not, depends on the front-end you use. If a setting is not supported, the front-end must silently ignore it.
The <@s>quiet@s> setting tells the front-end if how much should it show the progress of the processing session on the screen. The accepted values are <@c>true@c>, <@c>false@c> (of type string or boolean), and <@c>reallyQuiet@c>. Also, empty string is equivalent with <@c>true@c>. (Values <@c>-1@c>, <@c>0@c>, <@c>1@c> are also supported for backward compatibility.) The precise meaning of values is front-end specific.
The <@s>echoFormat@s> setting specifies how to display the progress of the processing session on the screen. The meaning of values and the set of understood values are front-end specific, but values <@c>verbose@c>, <@c>normal@c>, <@c>terse@c> and <@c>quiet@c> should be understood, also the shorthands of them: <@c>v@c>, <@c>n@c>, <@c>t@c> and <@c>q@c>. The front-end must not stop with error if it doesn't understand the value that comes from a configuration file.
The <@s>columns@s> setting specifies the number of columns on the console (terminal), which is used for text wrapping. This is only applicable if you are using a command line interface for FMPP (or something similar). If you are using the provided shell script to invoke the command line interface, that will try to auto-detect the actual value (since 0.9.15), so you shouldn't set this setting, unless the auto-detection gives incorrect result.
The <@s>printStackTrace@s> setting specifies if the front-end should print stack trace to the screen on error, or a terser error description. <@s>snip@s> is deprecated, and now it's just the inverted alias of <@s>printStackTrace@s>.
Please read the documentation of <@a href="frontends.html">the front-end you use@a> for the precise behavior of these settings.
@sect> <@sect title="Meta settings" anchor="metaSettings"> <@setting name="configurationBase" type="string (path)" default="" merging=false /> <@setting name="inheritConfiguration" type="string (path)" default="" merging=false />These settings influence the interpretation of the configuration file they are stored in. Although front-ends may support the specification of these settings outside configuration files, with the front-end specific interface, the meta setting specified in this way is used to emulate that the setting is present in the configuration file the front-end loads.
The <@s>configurationBase@s> setting sets the <@a href="configfile.html#configurationBase">configuration base@a> for the setting values stored in the same configuration file. If the <@s>configurationBase@s> itself is a relative path, then it is resolved relatively to the directory of the configuration file.
If <@s>inheritConfiguration@s> is present in a configuration file, then the configuration will <@a href="configfile.html#inheritance">inherit the configuration file@a> pointed by the value of this setting. If <@s>inheritConfiguration@s> is a relative path, then it is resolved relatively to the configuration base, which is already overridden by <@s>configurationBase@s> if that's persent in the configuration file.
@sect> <@sect title="XML related settings" anchor="xml"> <@setting name="xmlCatalogFiles" type="sequence (of paths)" default="" merging=true /> <@setting name="xmlCatalogPrefer" type="string" default="public" merging=false /> <@setting name="validateXml" type="boolean" default="false" merging=false /> <@setting name="xpathEngine" type="string" default="dontSet" merging=false /> <@setting name="xmlRenderings" type="sequence (of hashes)" default="ex:empty" merging=true /> <@sect title="Catalogs">Catalog files are (primarily) used to map public identifiers (and system identifiers) to local files. For example, you want to load an XML file that starts with this:
<@prg> @prg>Whenever you try to load this XML file, the XML parser will need the DTD requested by the DOCTYPE, so it will try to download it from <@c>http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd@c> (and all other files the DTD will refer to), which is obviously a bad joke. The standard solution is that you obtain the DTD file (and the further files it refers to) and store it locally on your computer, and also you write a catalog file that maps public identifiers (as <@c>-//W3C//DTD XHTML 1.0 Transitional//EN@c>) to the local paths of the files. Then, you have to specify the catalog file(s) for FMPP with the <@s>xmlCatalogFiles@s> setting.
FMPP supports the "widely known" catalog formats: OASIS plain text TR9401 catalog files, OASIS XML Catalogs, and XCatalogs. Delegate entries are supported. Don't panic if you can't undestand a word of it! :) Just look at <@example 'xml_validating' />. For most people it's enough to know (copy-paste...) what (s)he sees there. If you still need more information, please visit the Web page of the OASIS Entity Resolution Technical Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=entity.
The meaning of <@s>xmlCatalogPrefer@s> should be clean if you are familiar with OASIS catalogs. If you are not, just left it unchanged. The allowed values of this setting are <@c>system@c>, <@c>public@c>, and <@c>globalDefault@c>.
Both catalog related settings has a global (Java virtual machine level) default. Please find the documentation of <@c>org.apache.xml.resolver@c> package on the Internet about this. In the case of <@s>xmlCatalogFiles@s>, the global default will be appended at the end of the list of catalog files. In the case of <@s>xmlCatalogPrefer@s>, the global default is used when the value of the setting is <@c>globalDefault@c>. Attention! If you don't use the <@s>xmlCatalogFiles@s> FMPP setting, then the catalog feature is disabled, so you must specify this setting (even an empty sequence) to use the global defaults.
@sect> <@sect title="Validation">The <@s>validateXml@s> setting specifies if, by default, XML files are validated (i.e. checked against the DTD) or not. With "by default" I mean that this can be overridden for individual files, as with the <@c>validate@c> option of the <@a href="dataloader.html#key_xml">xml data loader@a>.
@sect> <@sect title="XPath engine">The <@s>xpathEngine@s> setting specifies which XPath engine will FreeMarker use when you access XML data (see <@a href="dataloader.html#key_xml">XML dataloader@a>). This setting accepts these values:
If you embed FMPP into your application, then you have to know that XPath engine choosing is a VM level setting (static field) of FreeMarker. Whenever you execute a processing session, FMPP will aggressively set this FreeMarker setting according the <@s>xpathEngine@s> FMPP setting. Thus, if you don't want FMPP to interfere with other FreeMarker dependent components in the same VM, you should keep value <@c>dontSet@c>.
@sect> <@sect title="XML rendering" anchor="xmlRendering">XML rendering is similar to the typical XSLT usage pattern, if you know that. The source file, for which <@c>renderXml@c> processing mode is choosen (see the <@s>modes@s> setting), will be parsed as XML file. Then, this XML document will be rendered to one or more output files with a FreeMarker template, which is choosen based on the value of the <@s>xmlRenderings@s> setting. The template gets the XML documents with the <@a href="pphash.html#key_doc"><@c>pp.doc@c> variable@a>. Since the template shouldn't be executed in itself, it should be an ignored file (for example it should be stored in a directory that has an <@c>ignoredir.fmpp@c> file).
For an example of this pattern check <@example 'xml_rendering'/>.
<@note>Sometimes you rather want to handle XML files as data than as source files. In this case use <@s>data@s>, <@s>localData@s>, or <@a href="pphash.html#key_loadData"><@c>pp.loadData@c>@a> with the <@a href="dataloader.html#key_xml">XML data loader@a>, not XML rendering.@note>The <@s>xmlRenderings@s> setting stores a sequence of XML rendering configurations. An XML rendering configuration is a hash that stores the options of an XML rendering. The options are:
Example:
<@prg><#noparse> xmlRenderings: [ { ifDocumentElementIs: product template: renderer/product.html xmlns: {D: http://example.com/xmlns/products} } { ifDocumentElementIs: book template: renderer/book.html index: { element: [part, chapter] attribute: ppFile numbering: hierarchical value: '%e_%n.html' } } ] #noparse>@prg>When <@c>renderXml@c> processing mode is chosen for a source file (see <@s>modes@s>), then the first matching XML rendering configuration of the sequence will be used. A configuration is matching if nor the <@c>ifSourceIs@c>, nor the <@c>ifDocumentElementIs@c> option excludes the XML file. (Thus, if a configuration doesn't use any of the <@c>if<@r>...@r>@c> options, it will be used for all source files, unless an earlier configuration matches the source file too.)
@sect> @sect> <@sect title="FreeMarker links (external includes)"> <@setting name="freemarkerLinks" type="hash (of sequence of paths)" default="" merging=true />FreeMarker links is a dirty hack to satisfy a frequent demand: <@c><#include ...>@c>/<@c><#import ...>@c> files that are outside the source root directory, as common FTL macro libraries used in multiple projects.
Assume you store your commonly used FreeMarker includes in the <@c>c:\user\freemarker\include@c> directory. But, this directory is outside the <@s>sourceRoot@s>, so you can't reach it with <@c><#include ...>@c>/<@c><#import ...>@c>. To solve this, add this to the FMPP configuration file:
<@prg><#noparse> freemarkerLinks: { inc: c:/user/freemarker/include } #noparse>@prg>Now you can include files of that external directory like this:
<@prg><#noparse> <#include "/@inc/foo.ftl"> #noparse>@prg>Here, FreeMarker will actually read <@c>c:\user\freemarker\include\foo.ftl@c>. The seeming <@c>@inc@c> entry in the source root directory (seeming, as there is no such file or directory there in reality) acts as an alias, a transparent link to <@c>c:\user\freemarker\include@c>. (Note that in the configuration file I have used <@a 'overview.html#realPath'>slash instead of backslash for convenience@a>.)
It is important that link entries (as <@c>@inc@c> above) are visible only for the predefined FreeMarker directives that use template paths (in FreeMarker 2.3, these are <@c><#include ...>@c> and <@c><#import ...>@c>), or for user defined directives that internally use those predefined directives. They are not visible for anything else. Thus, they are not visible for the functions and directives of the <@c>pp@c> hash, nor FMPP will try to process the <@c>@inc@c> directory (since it doesn't see it at all).
As you have seen, a link is defined by associating a name (<@c>inc@c> in the last example, but you can use anything else you prefer) with a path. You can have more links with different names. The link is visible in the source root (never in its subdirectories) as a directory (or file) of name <@c>@<@r>name@r>@c> (where <@c><@r>name@r>@c> is the link name). Regarding the associated path, the rules are the same as with <@s>sourceRoot@s>, <@s>outputRoot@s>, ...etc: it is a <@a 'overview.html#realPath'>real path@a>, so if it is relative, then it will be interpreted relatively to the <@a 'overview.html#realPath'>configuration base@a>.
For example, assume, that you also have project specific include files, and you store them outside the source root (because you have multiple source roots in your project), in the <@c>include@c> subdirectory of the same directory, where you stores the FMPP configuration files for your project. Use this in the FMPP configuration file:
<@prg><#noparse> freemarkerLinks: { inc: /home/joe/freemarker/include projInc: include } #noparse>@prg>Note that the path associated with <@c>projInc@c> is a relative path, so it will be resolved relatively to the directory of the configuration file (unless you have overridden the configuration base, of course...). Now you can do things like this:
<@prg><#noparse> <#include "/@projInc/header.html"> <#include "/@inc/foo.ftl"> <#import "/@projInc/forms.ftl" as f> #noparse>@prg>If the configuration file that contains the above is <@c>/home/joe/projects/foo/cfg3.fmpp@c>, then <@c><#include '/@projInc/header.html'>@c> will read <@c>/home/joe/projects/foo/include/header.html@c>.
In the generic case, a FreeMarker link is associated with a list of paths. For example:
<@prg><#noparse> freemarkerLinks: { inc: [/home/joe/freemarker/include, /home/kate/freemarker/include] } #noparse>@prg>When you use <@c><#include '/@inc/foo.ftl'>@c> in a template, then FMPP will check if <@c>/home/joe/freemarker/include/foo.ftl@c> exist, and if not, it will try <@c>/home/kate/freemarker/include/foo.ftl@c>.
Files that are really in the source root directory have priority over files that are accessible through FreeMarker links. For example, if you invoke <@c><#include '/@inc/foo.ftl'>@c>, and the source root directory has a subdirectory called <@c>@inc@c>, and that subdirectory has a file called <@c>foo.ftl@c>, then that file will be used, without considering that the <@c>@inc@c> in the path possibly refers to a FreeMarker link. If a subdirectory called <@c>@inc@c> exists, but it doesn't contain <@c>foo.ftl@c>, then the <@c>inc@c> link will be used.
A FreeMarker link can point to files as well, not only to directories. For example:
<@prg><#noparse> freemarkerLinks: { footer: /home/joe/footers/gpl.html } #noparse>@prg>and then in a template you can do this:
<@prg><#noparse> <#include "@footer"> #noparse>@prg>The merging of the <@s>freemarkerLinks@s> settings is differs a bit from the merging of other hash settings: when the two hashes to merge contains the same key (i.e. the same link name), then the lists of paths for that key will be concatenated. For example, if <@c>common.fmpp@c> is:
<@prg><#noparse> freemarkerLinks: { a: c:/user/fm/libs1 b: [inc1, inc2] } #noparse>@prg>and <@c>config.fmpp@c> is:
<@prg><#noparse> inheritConfiguration: common.fmpp ... freemarkerLinks: { a: c:/user/fm/libs2 b: [inc3, inc4] c: foo } ... #noparse>@prg>then the resulting setting value is equivalent with:
<@prg><#noparse> freemarkerLinks: { a: [c:/user/fm/libs2, c:/user/fm/libs1] b: [inc3, inc4, inc1, inc2] c: foo } #noparse>@prg>Note that the name of the links doesn't start with <@c>@@c>; the <@c>@@c> is used only to refer to the links. To protect users from mistakes regarding this, it is not allowed to start a link name with <@c>@@c>.
@sect> <@sect title='Activating fixes/improvements' anchor="freemarkerIncompatibleImprovements"> <@setting name="recommendedDefaults" type="string (version number)" default="0.9.15" merging=false since='0.9.16' /> <@setting name="freemarkerIncompatibleImprovements" type="string (version number)" default={ '0.9.15': '2.3.0', '0.9.16': '2.3.28' } merging=false since='0.9.15' /><@s>recommendedDefaults@> influences the default value of other settings. The setting value defaults will be those recommended as of the specified FMPP version. When you start a new project, set it to the current FMPP version (${pp.version} currently). In older projects changing this setting can break things, so check how the defaults change:
The lowest allowed <@s>recommendedDefaults@> value is 0.9.15, and the highest allowed is the version of the FMPP release that you are using.
<@s>freemarkerIncompatibleImprovements@> enables the FreeMarker fixes/improvements that are not 100% backward compatible, and were implemented in the FreeMarker version given in this setting. In older projects using the highest available <@c>2.3.<@r>x@r>@c> usually works fine, but check what changes <@a href="freemarker/api/freemarker/template/Configuration.html#Configuration-freemarker.template.Version-">in the documentation@>. New projects should definitely use the maximum, which is the version of the FreeMarker used (<@c>fmpp --version@> will print that, also, the current FMPP version was built with FreeMarker ${pp.freemarkerVersion}). See <@a href="freemarker/api/freemarker/template/Configuration.html#Configuration-freemarker.template.Version-"><@c>Configuration(Version)@c> in the FreeMarker API@a> for more information, such as what fixes/improvements are activated.
The format of both these settings is <@c><@r>major@>.<@r>minor@r>.<@r>micro@r>@c>, where each part is a positive integer without padding 0-s.
@sect> <@sect title="Object wrapping" anchor="objectWrapping"> <@setting name="objectWrapper" type="string (BeanShell expression)" default={ '0.9.15': '"b = new BeansWrapperBuilder(freemarkerIncompatibleImprovements); b.setSimpleMapWrapper(true); return b.build();"', '0.9.16': '"b = new DefaultObjectWrapper(freemarkerIncompatibleImprovements); ...; return b.build(); /* See fmpp.Engine constructor JavaDocs */"' } merging=false />The <@s>objectWrapper@s> setting is for FreeMarker "experts" who want to use a customized <@c>ObjectWrapper@c>. The value of the setting is a BeanShell expression that must result in an object whose class extends the <@c>freemarker.ext.beans.BeansWrapper@c> class. The value can be a simple expression like <@c>"new com.example.MyWrapper()"@c>, or multiple instructions ending with a <@c>return@c> statement.
The <@c>freemarker.template.ObjectWrapper@c>, <@c>freemarker.template.DefaultObjectWrapper@c>, <@c>freemarker.template.DefaultObjectWrapperBuilder@c>, <@c>freemarker.ext.beans.BeansWrapper@c>, and <@c>freemarker.ext.beans.BeansWrapperBuilder@c> classes are automatically imported, so you don't have to use full-qualified class name for them. Also, a non-<@c>null@c> <@c>freemarkerIncompatibleImprovements@c> value is exposed, which corresponds to the effective value of the similarly named FMPP setting.
The <@c>ObjectWrapper@c> is created before other setting values (or the <@c>fmpp.Engine@c> instance for that mater), so the BeanShell expression has no access to any setting values, except to <@s>freemarkerIncompatibleImprovements@s>, as it was shown.
The default value shown is actually only used when <@s>freemarkerIncompatibleImprovements@s> is at least <@c>2.3.21@>. For more information please consult <@a href="api/fmpp/Engine.html#Engine-freemarker.template.Version-freemarker.template.Version-freemarker.ext.beans.BeansWrapper-">the JavaDoc of the <@c>fmpp.Engine@c> constructor@a>.
@sect> <@sect title="Template syntax" anchor="templateSyntax"> <@setting name="tagSyntax" type="string" default='ex:<@c>angleBracket@c>' merging=false />The <@s>tagSyntax@s> setting determines the syntax of tags in the templates (angle bracket syntax like <@c><#include "foo">@c> VS square bracket syntax like <@c>[#include "foo"]@c>) that has no <@c>ftl@c> directive in it. If the template uses <@c>ftl@c> directive (like it starts with <@c><#ftl>@c> or <@c>[#ftl]@c>), then the syntax of the <@c>ftl@c> tag determines the syntax of the template, and the <@s>tagSyntax@s> setting is ignored.
The possible values of this setting are <@c>angleBracket@c>, <@c>squareBracket@c> and <@c>autoDetect@c>. The recommended value is <@c>autoDetect@c>, which will auto-detect the syntax of each template independently, by choosing the syntax of the first FreeMarker tag in the template. For example when it finds a <@c>[@@c> in the template, it will choose square bracket syntax.
<@setting name="interpolationSyntax" type="string" default='ex:<@c>legacy@c>' merging=false since="0.9.16" />The <@s>interpolationSyntax@> setting determines the syntax of the interpolations (where you insert a value, like <@c><#noparse>${#noparse><@r>name@>}@>) in templates.
The possible values of this setting are <@c>legacy@c> (like <@c><#noparse>${#noparse><@r>expression@>}@> and the deprecated <@c><#noparse>#{#noparse><@r>numericExpression@>}@>), <@c>dollar@c> (means <@c><#noparse>${#noparse><@r>expression@>}@> only), and <@c>squareBracket@c> (like <@c>[=<@r>expression@>]@>. The recommended value is <@c>dollar@c>, unless the <@c><#noparse>${#noparse>@> pattern clashes with the static parts that you need to generate (like when you generate JSP or shell script), in which case use <@c>squareBracket@c>. The default is <@c>legacy@c> (as far as that's the default of FreeMarker).
@sect> @page>