INFO and INFOVARS
The proposal involves two LST tokens:
INFO:x|y
- x is an "info name". This is data defined
- y is the message format. It matches the format required by java.text.MessageFormat, which can be found, among many other places, here: http://docs.oracle.com/javase/7/docs/api/java/text/MessageFormat.html#getFormatsByArgumentIndex%28%29
- This token overwrites (if the "info name" matches)
INFOVARS:x|y=z|y=z
- x is an "info name". This is data defined
- y is a scope from the new Formula System (e.g. AREA). The y= is optional if y is "VAR" (the default numeric variable scope)
- z is a variable from the new Formula System (e.g. Face)
- This token overwrites (if the "info name" matches)
Some notes:
The "info name" is dynamic. It is NOT under the control of something like the data control file (it is NOT like FACT names or Variables). It is more similar to today's Aspect names.
There are rules for the "info name" regarding use in INFO and INFOVARS. Specifically:
If an info name is used in INFOVARS but never in INFO on that object, it is an LST load error
If an info name is used in INFO and the Message Format requires variables and no INFOVARS is provided, it is an LST load error
If an info name is used in INFO and the Message Format requires N variables and the number provided to INFOVARS does not match N, then it is an LST load error.
Note: The "info name" is only so flexible, but the code will not restrict it at this time. I would advise the data standard be all letters
and numbers (no spaces, no special characters), and if we can get to a standard the data team wants strongly enforced, that can be done.
Output in the new Freemarker system is implied. Any INFO token will be available under *.info . For example:
- Race LST file
- Monkey <> INFO:Wildness|Monkeys are usually found in the wild
- can be accessed under the following:
- pc.race.info.wildness
