On This Page
advertisement

Text Templates create Field values that you want to use in your genealogy application. Text Templates are processed when ORA is creating the OraPanel.

You may add one or more Text Templates for a collection. The output of each Text Template creates a new Field. The new Field will appear at the top or the bottom of the OraPanel as determined by the Add Fields at Top option. User Field Styles are applied to Text Template Fields.

OraPanel Field Created by Text Template with Default User Field Styles Applied

For information about adding and editing Text Templates, see the Editing Templates section of the OraSettings help page.

Templates consist of comment lines, literal text, variable references, and conditional expressions.

Variable references may include transforms. For general information about using transforms, see below. For information about specific transforms, see the Transforms help page.

Comment Lines

You may add comments to a template to describe its use or purpose. Start a line with the hash symbol ("#") and the remaining text on that line is ignored by the template processor.

The hash symbol must be the first character. If other characters, including whitespace characters, occur before the hash symbol, the text will not be treated as a comment.

You may add comment lines to Text Templates, Auto Type Templates, and library templates.

In the unlikely case that you require a hash symbol as the first character on a line without creating a comment, precede the hash symbol by the escape character ("\").

Examples

  1. The first line is a comment because it begins with a hash symbol. The template output is determined by the second line of the template:
    # This is a comment
    <City: [City]><; State: [State]>
  2. The first line is NOT a comment because the hash symbol is preceded by the escape character. The template output is a hash symbol followed by the value of the Record ID Field:
    \#[RecordId]

Literal Text

Literal text is any text that is not part of a Variable Reference or Conditional Expression. Use literal text to add punctuation, labels, or other text to the output.

Newline Characters

Newline characters are an exception to the handling of literal text because they are ignored in templates. You may use them to add structure to a template and make it easier to separate different parts of a template into logical sections.

Text Templates produce text that appears in the OraPanel. See the Newlines in Fields section below to learn how to add newlines to a Field value there.

For instructions on how to include a newline in text you send to your genealogy application, see the Newlines topic on the Auto Type page.

Variable References

Field values are inserted into the output using variable references. [Name] is an example of a variable reference. When processing that variable reference, ORA will insert the Name value into the output.

A variable reference starts with "[" and ends with "]". The text inside must begin the label of one of the Fields in the OraPanel with exceptions as described below in the Special References section. You may use one or more Transforms to alter the value as described below in the Transforms section.

When processing a variable reference, ORA substitutes the value of the Field into the output in place of the variable reference.

Conditional Expressions

In its simplest form, a conditional expression is used to insert a prefix and or suffix with a variable. <; Date:[Date]> is an example of a conditional expression. If the Date value is not empty, ORA will insert "; Date: " and the Date value into the output. If the Date is empty, the "; Date: " prefix will not be inserted into the output.

A conditional expression starts with "<" and ends with ">".

If a conditional expression includes more than one variable reference, all the variable references must be "true" or the conditional expression will be considered "false". For most variable references, a non-empty Field value is considered "true" and an empty Field value is "false".

You may nest conditional expressions.

If an outer conditional expression includes only literal text, at least one of its nested conditional expressions must be true or the outer expression's literal text will be suppressed.

Spaces are significant in ORA templates, and that includes spaces in conditional expressions.

Examples

  1. Include the Date value in the output with a prefix of "; Date: ":
    <; Date: [Date]>
  2. Include "Place: City", "Place: State", or "Place: City State" depending on which values are present:
    <Place:< [City]>< [State]>>

Alternatives

Alternatives are conditional expressions where the conditional text includes multiple expressions separated by |. The expressions are evaluated left-to-right and the first expression that produces text is included in the output. Any remaining expressions are ignored.

The general form is:

< expression1 | expression2 | ... >

Alternatives include special handling for literal text:

  • If an outer conditional expression has text only, such as the comma in <, <[A]><[B]>>, the outer text will be suppressed unless at least one of the inner conditions is true.
  • If an outer conditional expression has a variable reference, with or without text, such as the [A] in <, [A]<, [B]><, [C]>>, the outer variable and text will appear even if all the nested conditions are false.

Example

Include "Place: City, State" if either or both of City and State are present. This is an improvement on a prior example because this example includes the comma usually inserted between place components:

<Place:< [City], [State]| [City]| [State]>>

In the inner conditional expression, the first alternative is chosen if both City and State have non-empty values. The second alternative is chosen only if the first alternative was not chosen, and City is not empty. The third and final alernative will be chosen only if the first two were not chosen and if State is not empty.

If none of the inner expressions produce any output, i.e., if both City and State are empty, the literal text "Place:" will not appear in the output. If an outer expression has literal text only because all of its inner expressions were empty, the outer expression is considered "false" and the literal text is ignored. This allows you to design templates that include or omit labels based on the presence or absense of multiple Fields.

Transforms

ORA supports transform functions where you can change a value before inserting it in the output. See the Transforms page for a description of the available transforms.

The general form is:

[field-name:transform]

Parameters

Some transforms have parameters:

[field-name:transform:parameter1:parameter2]

Parameters vary based on which transform you are using. Parameters are separated by the colon character (":").

Parameters may include literal text or Field references. When using a Field reference as a parameter, wrap the Field name in the "[" and "]" characters as shown for "field2":

[field1:transform:[field2]]

You may include transforms and their parameters as part of the Field reference, and transform parameters may include Field references:

[field1:transform:[field2:transform:parameter...]]

Chaining

You may specify several transforms in succession. This is called "chaining".

[field-name:transform1:transform2:...]

For example:

[Children:numberToWords:capitalize]

If you are chaining transforms, and using a transform that includes optional parameters, you must specify all parameters, optional or not, before you add any subsequent transform(s).

Special References

Value Test

If a variable reference begins with "?:", ORA treats it as a value test. Value tests are used in conditional expressions to vary the output of a template based on the value of a Field.

The value test variable relies on the method ORA uses to process conditional expressions. Each conditional expression is evaluated based on the true or false result of each variable reference or nested conditional expression. In the simple case of [Name], the result is true if the Field is not empty and false otherwise. However, ORA doesn't actually depend on the variable inserting text into the output. It evaluates whether the function that processed the variable returned true or false. This means it is possible for a variable reference to return true even though it did not append any text to the output.

There are several forms of the value test as shown in the list below.

In the list, assume that "Name" is a Field in the current record. The comparand is the value in the expression, so in [?:Name=Maureen], the comparand is "Maureen".

  • Not Empty: [?:Name] — This variable will have a true value if Name is not empty.
  • Equal: [?:Name=Maureen] — This variable will have a true value if Name is equal to "Maureen". The comparison is not case-sensitive, so values of "Maureen", "MAUREEN", "maureen", etc., are considered equal.
  • Equal (case-sensitive): [?:Name==Maureen] — This variable will have a true value if Name is exactly equal to "Maureen". The comparison is case-sensitive, so values that differ in case only, such as "MAUREEN" and "maureen", are not considered equal.
  • Not Equal: [?:Name!=Maureen] — This variable will have a true value if Name is not equal to "Maureen". The comparison is not case-sensitive, so values of "Maureen", "MAUREEN", "maureen", etc., are considered equal.
  • Not Equal (case-sensitive): [?:Name!==Maureen] — This variable will have a true value if Name is not exactly equal to "Maureen". The comparison is case-sensitive, so values that differ in case only, such as "MAUREEN" and "maureen", are not considered equal.
  • Greater Than: [?:Age>5] — This variable will have a true value if Age is greater than 5. The comparison is numeric if both the Field value and the comparand are numeric.
  • Greater Than or Equal To: [?:Age>=5] — This variable will have a true value if Age is greater than or equal to 5. The comparison is numeric if both the Field value and the comparand are numeric.
  • Less Than: [?:Age<5] — This variable will have a true value if Age is less than 5. The comparison is numeric if both the Field value and the comparand are numeric.
  • Less Than or Equal To: [?:Age<=5] — This variable will have a true value if Age is less than or equal to 5. The comparison is numeric if both the Field value and the comparand are numeric.
  • Regular Expression: [?:Name/ee/] — This variable will have a true value if Name contains "ee" or "EE", etc.

    The default Regular Expression flags value is "i". You may disable that flag by passing a space character after the trailing /, for example: [?:Name/ee/ ]

When comparing to another value (Equal "=" or Not Equal "!=") or evaluating a Regular Expression, comparisons are done case-insensitive meaning that a lowercase character and an uppercase character are considered the same character. For Equal (case-sensitive) "==" or Not Equal (case-sensitive) "!==", comparisons are case-sensitive and a lowercase character and an uppercase character are not considered the same character.

Examples

  1. Include "Place: City, State" if either or both of City and State are present. This is a variation of a prior example that demonstrates how to use a value test for a non-empty Field:
    <Place:< [City]><<[?:City],> [State]>>

    The comma between City and State is inserted only if City is not empty; that's what <[?:City],> does.

  2. Include "Owned" if "Own or Rent" is equal to "o" or "O":
    <[?:Own or Rent=o]Owned>

    The value test <[?:Own or Rent=o] is true if Own or Rent is equal to uppercase or lowercase "O" (Oh). If it is true, then the literal text "Owned" that follows it in the expression will be inserted in the output.

  3. Include "Owned" if "Own or Rent" starts with "o" (lowercase oh), "O" (uppercase oh) or "0" (zero):
    <[?:Own or Rent/^[o0]/]Owned>

    The Regular Expression /^[o0]/ will only match values that begin with either "o", "O", or "0". If Own or Rent starts with one of those characters, then the literal text "Owned" that follows it in the expression will be inserted in the output.

    This expression would be useful if records were transcribed by character recognition and some instances of letter "O" were mistranscribed as zeroes.

Value Test - Dates

When evaluating a Value Test, if ORA determines that both the Field value and the comparand value are dates, it uses a date comparison rather than a string comparison. In a date comparison, the parts of each date (year, month, and day) are converted to numbers and the parts are compared in year, month, day sequence.

You may specify the comparand value using any of the formats that ORA recognizes as a date, so "1 MAR 1998" is valid as is "1998-03-01".

Both the Field value and the comparand may be full dates or partial dates. Full dates include year, month, and day. Partial dates include a year only or a year-and-month only. ORA uses the parts in the comparand to determine which parts to compare.

The Field value and the comparand value may have a different number of parts. So, for example, if Date is "3 FEB 1905" and the Value Test is [?:Date=1905], the Field value has year, month, and day, but the comparand value is a year only. ORA uses the comparand value to determine which parts to compare, so in this example it will compare the year values only, and the result is true.

When the Field value does not have all the parts that are specified in the comparand value, ORA will assume a "worst case" value for each missing part. This can lead to confusing results when the Field value is close to the comparand value. For example, if Date is "1905" and the Value Test is [?:Date<FEB 1905], the result is false. However, that does not mean that [?:Date>FEB 1905] is true, and in fact, the result is also false. ORA treats the Date value as ambiguous when it has less than the required parts, and so ORA doesn't know if "1905" is greater than or less than "FEB 1905". See the table below for more examples.

Examples

Value of Date Field Value Test Reference Result
1 JAN 1900[?:Date<1900]False
The comparand date has a year only, so ORA only compares the year from Date ("1900") to the comparand ("1900"). "1900" is not less than "1900", so the result is false.
1 JAN 1900[?:Date=1900]True
The comparand date has a year only, so ORA only compares the year from Date ("1900") to the comparand ("1900"). "1900" is equal to "1900", so the result is true.
1 JAN 1900[?:Date>1900]False
The comparand date has a year only, so ORA only compares the year from Date ("1900") to the comparand ("1900"). "1900" is not greater than "1900", so the result is false.
1899[?:Date<1900]True
The comparand date has a year only, so ORA only compares the year from Date ("1899") to the comparand ("1900"). "1899" is less than "1900", so the result is true.
1899[?:Date=1900]False
The comparand date has a year only, so ORA only compares the year from Date ("1899") to the comparand ("1900"). "1899" is not equal to "1900", so the result is false.
1899[?:Date>1900]False
The comparand date has a year only, so ORA only compares the year from Date ("1899") to the comparand ("1900"). "1899" is not greater than "1900", so the result is false.
1900[?:Date<FEB 1900]False
The comparand date has a year and month, but Date has a year only. ORA uses the "worst-case" value for the month, which is December for a "less than" comparison. It compares the adjusted Field value ("DEC 1900") to the comparand ("FEB 1900"). "DEC 1900" is not less than "FEB 1900", so the result is false.
1900[?:Date=FEB 1900]False
The comparand date has a year and month, but Date has a year only. For an "equal to" comparison, the Field value must have all the date parts that exist in the comparand, and in this example, it does not, so the result is false.
1900[?:Date>FEB 1900]False
The comparand date has a year and month, but Date has a year only. ORA uses the "worst-case" value for the month, which is January for a "greater than" comparison. It compares the adjusted Field value ("JAN 1900") to the comparand ("FEB 1900"). "JAN 1900" is not greater than "FEB 1900", so the result is false.
1899[?:Date<FEB 1900]True
The comparand date has a year and month, but Date has a year only. ORA uses the "worst-case" value for the month, which is December for a "less than" comparison. It compares the adjusted Field value ("DEC 1899") to the comparand ("FEB 1900"). "DEC 1899" is less than "FEB 1900", so the result is true.
1899[?:Date=FEB 1900]False
The comparand date has a year and month, but Date has a year only. For an "equal to" comparison, the Field value must have all the date parts that exist in the comparand, and in this example, it does not, so the result is false.
1899[?:Date>FEB 1900]False
The comparand date has a year and month, but Date has a year only. ORA uses the "worst-case" value for the month, which is January for a "greater than" comparison. It compares the adjusted Field value ("JAN 1899") to the comparand ("FEB 1900"). "JAN 1899" is not greater than "FEB 1900", so the result is false.

Multiple Value Test

If a variable reference begins with "??:", ORA treats it as a multiple value test. Multiple value tests are used in conditional expressions to ensure that multiple Fields have a value. This is a convenience feature that makes it simpler to test whether multiple Fields all have a value.

See Value Test above for an explanation of how ORA evaluates conditional expressions and how a variable reference can return true or false even though it does not add any text to the output.

The multiple value test accepts one or more Field names. If all the Fields have a value, the result is true. Otherwise, the result is false.

You cannot use comparison operators like "=", ">", etc., with a Multiple Value Test.

Example

  1. [??:City:State]

    Returns true if both [City] and [State] have non-empty values.

Plus or Minus

If a variable reference begins with "+" (plus) or "-" (minus), the output will vary based on the prior output of the template. The plus and minus variables simplify templates where you want to vary the output based on the output from prior Field values. The plus and minus variables are intended to be used in conditional expressions and they inspect the output of the prior nesting level.

There are four variations of the plus and minus variables.

  • The [+] variable returns true if the prior output is not empty. It is used to process an alternative only if prior sibling expressions have produced text. You can use it to add a Field value to the output only if one or more prior Fields are not empty.
  • The [-] variable is the opposite of [+]; [-] returns true if there is no prior output. You can use it to add a Field value to the output only if one or more prior Fields are empty.
  • The [+:text] variable always returns true. It will insert the specified text if the output of the prior nesting level is not empty.
  • The [-:text] variable always returns true. It will insert the specified text if the output of the prior nesting level is empty.

The most common use of these variables is to insert a comma or other punctuation between Fields where one or more of the Fields may be empty and you do not want the punctuation before the first non-empty Field.

Example

Include "Place: City, County, State" with commas between the second and subsequent Fields. This is a more difficult variation of prior examples but shows the simplest solution overall.

<Place: <<[City]><[+:, ][County]><[+:, ][State]>>>

City, County, and State are all conditional. They are enclosed by an outer conditional expression so that the <[+:, ]> variable inspects the output of the three Fields and not the literal "Place: " that is at the outer-most level and should only appear if at least one of the place Fields is not empty.

Assignment

If a variable reference begins with "=:" or "==:", ORA treats it as a value assignment. You may use a value assigment to change the value of an existing Field or to create a new Field name and value. Value assignments are used when you want to be prompted to enter a value. They are also useful when testing templates.

An Assignment reference does not create any output, and the result of the expression is always true.

The general form is:

[=:name:value]

or

[==:name:value]

The name parameter is required.

  • The single-equal sign variation ([=:name:value]) creates a temporary variable. The variable is discarded when ORA finishes processing the current template.
  • The double-equal sign variation ([==:name:value]) creates a persistent variable. The variable persists until you refresh the current page or navigate to a new page.
  • If you specify the name of an existing Field, its value will be changed for the duration of the template evaluation (for a temporary variable) or until a page refresh (for a persitent variable).
  • If the name value includes any of the following characters, they will be changed to a space:: / = ! < >

The value parameter is optional.

  • If you do not enter a colon following the name, you will be prompted to enter a value for the Field.

    If you click the [Cancel] button in response to an assignment prompt, ORA will stop evaluating the template and the template will produce an empty value.

    If you click [OK] without keying any text, the variable value will be empty, but unlike clicking [Cancel], execution of the template will continue.

  • If you enter a colon and no other characters, the value will be an empty string. You can use this expression to unset a Field value.
  • If you enter a colon and additional characters, the value will be set to whichever characters you supply.
  • If you enter a colon and additional characters that begin with "[" and end with "]", ORA will treat the value as a Field reference and use that Field reference to determine the value to assign. The Field reference may include transforms.

    If there is any character, even a space, before the leading "[" or after the trailing "]", ORA will treat the characters as literal text and not as a Field reference.

Assignment references are useful during template testing. You can add one or more assigments to the beginning of a template to review the template output for values that don't occur in the current collection record but may occur in other records.

Assignment references are also useful if your template has two or more references to a transform expression. Rather than repeat the expression, save the result of the transform in a temporary variable and refer to that variable multiple times.

You may use Assignment references to prompt you to enter a value. This usage is not recommended in Text Templates because you will be prompted every time you visit a record in the collection. That will be annoying. For Auto Type Templates, however, a prompt may be useful and the prompt will only occur when you click the OraPanel button associated with the Auto Type Template.

Persistent Variables

As described above, the double-equal Assignment reference creates a persistent variable. Persistent variables will retain their value even if you refresh the OraPanel. The variable will exist until the current page is refreshed or until you navigate away to another page. If you navigate back, the persistent variable will only exist if it is recreated by a Text Template.

Double-equal Assignment references and the persistent variables they create are mostly intended for usage cases where you want an Auto Type Template to prompt you to enter one or more new values, and you want subsequent Auto Type Templates to use those values.

For example, if you want to enter a value that is not extracted from an image, and that value is used by several Auto Type Templates, you only want to be prompted once to enter the value. You can create a "prompt-only" Auto Type Template that prompts you to enter one or more values. Other Auto Type Templates may then refer to the variable and will not need to prompt for it.

For example, to create a persistent variable named "Source.ED" (Enumeration District):

{target=none}[==:Source.ED]

Text Templates create Fields in the OraPanel. Those Fields are recreated when you refresh the OraPanel which is roughly equivalent to being persistent. If you can set a value without prompting, you may want to use a Text Template. If you need a prompt to set the value, you should avoid using a Text Template. You do not want to be prompted every time you visit a record in the collection or refresh the OraPanel. Instead, use a prompt-only Auto Type Template. You will not be prompted until you click the Auto Type Template button.

Another option for creating persistent values is to use the Add Field button.

Library Template References

ORA's Template Library provides a way for users to store frequently-used template text in a library. Each item in the library is a library template that can be used by any collection template. This helps reduce repetition in collection templates.

To insert a library template into a collection template, you add a library template reference to the collection template. You may add a library template reference to both Text Templates and Auto Type Templates in any collection in any repository.

A library template reference uses syntax that is similar to Variable References but it must begin with the special prefix "lib.":

[lib.name]

For more details, see the Template Library help page.

Indirect References

If a variable reference begins with the ^ character, ORA treats it as an indirect reference where the value of the variable is treated as the name of another variable. The indirect reference returns the value of the indirectly named variable.

For example, if "var1" has the value "var2", and "var2" has the value "17 February 1928", the value of [var1] is "var2" and the value of [^var1] is "17 February 1928".

Example 1

Indirect References are intended for use with the special option value o.Template Name.

  1. Add a Library Template:
    Name Enter
    Template
    <[^o.Template Name]|ENTER>

    The Library Template returns the existing value of the Text Template that uses the Library Template, or "ENTER" if the value is empty.

  2. Add a Text Template:
    Heading Enum Date
    Template
    [lib.Enter]

    The Text Template lets the Library Template do all the work required. It does not have to refer to itself, which is simpler than the other implementation alternative and avoids errors.

Given the above, ORA will add a Field named "Enum Date" to the OraPanel. Its initial value will be "ENTER", but you can Alt-click to change that value.

The Text Template and the Library Template are possible without an Indirect Reference, but using one simplifies the Text Template. The Library Template determines the name of the Field it should assign using an Indirect Reference to o.Template Name.

Example 2

Indirect References can be combined with one or more transforms to create the name of the variable of interest. This can be useful when a vital records collection includes records where the fields names vary because some are births, some are marriages, and some are deaths.

Let's use two records from Massachusetts State Vital Records, 1841-1920 collection on Family Search, a birth record and a death record.

For the birth record, [^Event Type:append: Date] will return the value of the Birth Date field because [Event Type] is "Birth" and appending " Date" means the Indirect Reference is equivalent to [Birth Date].

For the death record, [^Event Type:append: Date] will return the value of the Death Date field because [Event Type] is "Death" and appending " Date" means the Indirect Reference is equivalent to [Death Date].

You can see this in action by adding a Text Template for that collection as follows:

Heading Event Date
Template
<
[Event Date]
|
[^Event Type:append: Date]
>

When processing [^Event Type:append: Date],

  1. ORA gets the value of [Event Type], which is "Birth" for a Birth record.
  2. ORA appends " Date" to "Birth" which yields "Birth Date".
  3. ORA applies the redirect operator on that value ("Birth Date") and returns "1884" for the example record.

Trace References

The [Test...] button on the OraSettings page evaluates a template and displays the result in the Template Tester panel. That panel includes a Trace section. The Trace section shows the logic and true/false results processed during template evaluation. The entries are indented to show the nesting of conditional expressions. If your template does not produce the output you expect, the trace may help you determine why.

To insert literal text into the trace output, you add a trace reference to the template. You may add trace references to both Text Templates and Auto Type Templates.

A trace reference uses syntax that is similar to Variable References but it must begin with the special prefix ":", i.e., you must omit the Field or variable name. The text after the colon is written to the trace output.

[:This is written to the trace output]

Option Values

Templates may refer to the following variables that have an "o." prefix.

  • [o.Service] — Returns the name of the current service, such as "FamilySearch".

    Template authors may use [o.Service] to vary the behavior of a template based on whether or not it is being run with a record from a particular service. This is mostly intended for use with Template Library templates that may be used by templates for multiple services.

  • [o.Template Name] — Returns the name of the current Text Template or Auto Type Template.

    This is mostly intended for Library Templates where knowing the name of the Text Template simplifies usage. See Indirect References.

  • [o.Test] — Returns "1" when running via the [Test] button on the OraSettings page. Otherwise, returns "0".

    Template authors may use [o.Test] to vary the behavior of a template based on whether or not it is being run via the [Test] button.

  • Special Text Templates

    Tab.Title

    "Tab.Title" Text Templates do not appear in the OraPanel and their values are not available to other templates.

    If the Heading value of a Text Template is "Tab.Title", ORA will evaluate the template and use the result as the title for the browser tab when the collection appears in a browser tab. Adding a Tab.Title Text Template is useful when the tab title assigned by the repository is confusing or not useful.

    For example, the Nova Scotia Historical Vital Statistics repository sets the tab title to "Item View" when viewing record images:

    NovaScotiaGenealogy.com Marriage Record

    "Item View" is not useful when you have multiple tabs open and you want to switch back to a particular tab. To customize the tab title for records in the NovaScotiaGenealogy.com Marriage collection, add a Text Template named "Tab.Title":

    NovaScotiaGenealogy.com Marriage Collection "Tab.Title" Template

    The template above sets the tab title to "surname1/surname2 year" using the nameSurname transform to extract the surnames from the names. For my usage, the icon for NovaScotiaGenealogy.com is enough to identify the repository. The surnames of the spouses and the year provide enough context to identify a marriage record in most if not all circumstances where I have records open in multiple tabs.

    Customize the "Tab.Title" template to suit your preference.

    After adding or modifying the Text Template, refresh the OraPanel to see the custom tab title:

    NovaScotiaGenealogy.com Marriage Record with custom Tab.Title

    See the Tab.Title Template Suggestions page for Tab.Titles you may wish to add to you ORA configuration.

    Variable Templates

    Text Templates whose headings begin with "var." do not appear in the OraPanel.

    If the Heading value of a Text Template begins with "var.", ORA will evaluate the template and save its value in the Field collection (as is true of most other Text Templates) but it will not show the Text Template in the OraPanel. This is useful for creating values that you use in subsequent Text Templates or Auto Type Templates. It centralizes the definition of a value so you can define it once and use it in multiple places without cluttering the OraPanel.

    For example, if you want to parse a state from a place, you might create a Text Template as follows:

    Heading:var.State
    Template:[Place:placeState]

    In a subsequent template, you can refer to the Text Template value with "[var.State]".

    Advanced Techniques

    Text Template Fields

    When ORA processes a Text Template for a collection, the result is added to the OraPanel. The result is also added to the Fields that are associated with the collection. This can be useful for generating intermediate results that are subsequently used by other templates. Any Text Template can refer to the Field for any other Text Template with a lower number, and any Auto Type Template can refer to any Text Template.

    The Field name is the heading of the Text Template. So, for example, if you add a Text Template with the heading "Citation Detail", you can refer to the output of the template in a subsequent template using [Citation Detail].

    You may use this capability to reduce or eliminate repetitive computation of the same value, such as when you have two or more Auto Type Templates that transform a Field to match your data entry standards.

    It can be confusing to test templates that refer to an other Text Template because Text Templates are only evaluated when viewing a record in the collection. If you change a Text Template, then immediately test another template that refers to the changed Text Template, you won't see any difference. You have to visit or refresh the OraPanel for a record in the collection so that ORA will update the Text Template values for that collection.

    Editing Text Template Results

    If you want to be able to edit the value of a Text Template when it appears in the OraPanel using ORA's Edit Field feature, you must use a template that follows the structure described below.

    When you edit any OraPanel Field, ORA updates the value and then refreshes the OraPanel. The refresh is necessary to allow for the case where Text Template 2 depends on the value of Text Template 1, etc. When ORA refreshes the OraPanel, it re-evaluates all the Text Templates, and their templates determine their values.

    Let's walk through an example.

    1. In your collection, you add a Text Template:

      Name: Enum Date
      Template: 1 Apr 1940

    2. You visit a record in the collection and you edit the "Enum Date" Field and set the value to "2 Apr 1940".
    3. ORA accepts the new value, then refreshes the OraPanel.
    4. In the course of updating the OraPanel, ORA re-evaluates all the Text Templates, including "Enum Date". "Enum Date" has a literal value, so ORA assigns "1 Apr 1940" to Enum Date.

    In summary, the refresh of the OraPanel triggers a re-evaluation of "Enum Date", and the original value is restored because the template consists solely of a literal.

    To allow a Text Template value to be edited, use a conditional expression in the template and only assign a value if there is not one set already.

    1. You change your Text Template as follows:

      Name: Enum Date
      Template: <[Enum Date]|1 Apr 1940>

    2. Once again, you visit a record in the collection and you edit the "Enum Date" Field and set the value to "2 Apr 1940".
    3. ORA accepts the new value, then refreshes the OraPanel.
    4. In the course of updating the OraPanel, ORA re-evaluates all the Text Templates, including "Enum Date". In this case, [Enum Date] already has a value, so the result of evaluating the template is the just-updated value, "2 Apr 1940".

    The conditional expression structure is:

    <[field-name]|default-value>

    ... where the default-value may be a literal or an expression, though the former is more typical.

    If the first alternative, [field-name], is empty, then ORA will evaluate the second alternative. The first time ORA evaluates the template the Text Template Field will not have a value. The result will be the default value.

    If the OraPanel is refreshed for any reason, the first alternative will not yield an empty result because [field-name] is not empty. The evaluation will produce the existing value, whatever that is. That will be the default-value if the Field was not edited, or it will be some other value if it was edited.

    It's a bit confusing because a reference to the Text Template is used within its own definition, but that's allowed and the technique described here depends on that capability.

    Valid State

    An abbr Transform may be used to determine if a state value is valid.

    <[?:State:abbr:us_states]valid state|invalid state>

    If State is not a valid state name, the value of [?:State:abbr:us_states] will be false. Substitute the output you want when the state is valid or invalid in place of the text used in the example.

    You may use the same technique with the other lookup tables.

    Conditional Prompt

    An Assignment reference without a value produces a prompt for the user to enter a value. If you only want the prompt if a Field is not present in a record or meets some other criteria, you can nest the Assignment reference in a conditional expression:

    <[?:City]|[=:City]>

    If City is empty, the Value Test [?:City] will be false and the second alternative will be evaluated. That alternative includes the Assignment reference which is a prompt because it has no value, and the user will be prompted.

    Newlines in Fields

    You may want to include linebreaks in the value of a Field that you add to the OraPanel using a Text Template. You cannot add newline characters to Field values because newline characters are ignored in Text Templates. Even if you could add a newline character, Field values that appear in the OraPanel are subject to the rules for HTML, and newline characters are ignored in HTML.

    Despite those circumstances, you can add a newline to a Field value in a Text Template. You do so by adding the HTML for a linebreak, which is <br>. However, because the "<" and ">" characters have a special meaning in Text Templates, you must escape them using the "\" character as follows:

    \<br\>