Explain Interpolations in FreeMarker

Description

In FreeMarker, there are interpolations. When we use FreeMarker to create an output sheet, we insert a set of interpolations. For purposes of this discussion, the main ones are "pc" and "pcgen".

In FreeMarker terms, both "pc" and "pcgen" are a hash ( see http://freemarker.org/docs/pgui_datamodel_parent.html ) . This means additional items can be accessed by adding a dot and further information.

"pcgen" returns information about the current "pcgen" installation. This means things like the software version would be included (they would not change from one character to another)

"pc" returns information about the current player character.

The detailed interplations may be scalar, hash, list, or other items, depending on the type of content. Any documentation request should specify what the more detailed item contains.

When an item is a CDOMObject (this is what a Feat, Stat, Check, Skill, Language, etc. are within PCGen), then by default the object is both a scalar (will return the name) and a hash (can get additional information). All of the actual hash content will be specified in NEWTAG entries... this is just an initial framework request to get thinking about how the new FreeMarker documentation should work.

Note one thing: Traditionally, output tokens were very static, in that each had their own syntax. In the new system, features will be rapidly shared across hashes. For example, there may be the following interpolations:
pc.alignment
pc.sizeadjustment
pc.deity

For each of those, many of the same suffixes will likely be valid. This includes things like:
.desc
.displayname
.outputname
... and others.

In other cases, an interpolation may be unique. For example, .abb will likely be usable on pc.sizeadjustment, but not pc.deity. This should be considered in how the docs are structured.

(One side effect of this being that any of the common items may rapidly grow the number of places in the documentation that need to be updated if it is not structured in a way that recognizes common behavior. The CHOOSE LST token docs chose NOT to have a common structure for things that are shared (TYPE=, PC, QUALIFIED, etc.), which means each has to be kept current. It is up to the Docs team on how it should be structured.

Environment

None

Assignee

Unassigned

Reporter

Tom Parker

Labels

None

Epic/Theme

None

Pending User Input

No

Components

Priority

Minor
Configure