Jon at 18:21, 7 July 2026

2026-07-07T18:21:33Z

Jon at 15:01, 7 July 2026

2026-07-07T15:01:10Z

Jon: Detailed description of `model.txt` and its usage within UI component specifications

2026-07-07T15:00:43Z

Detailed description of `model.txt` and its usage within UI component specifications

Show changes

@@ Line 149: / Line 149: @@
      INVISIBLE: The component is invisible.
      NONE: The component is both invisible and removed from the layout.</pre>
-In the above excerpt from <code>model.txt</code> for <code>Component</code>, the <code>visibility</code> property is defined within the <code>Styles</code> section. <code>visibility</code> can be one of three values: - <code>VISIBLE</code> - <code>INVISIBLE</code> - <code>NONE</code>
+In the above excerpt from <code>model.txt</code> for <code>Component</code>, the <code>visibility</code> property is defined within the <code>Styles</code> section. <code>visibility</code> can be one of three values:
 Each possible value is named and defined directly below the definition for <code>visibility</code>.
@@ Line 175: / Line 178: @@
      terms: The list of words from the name for the condition.
             name.split(' ')</pre>
-<code>conditions_list</code> is a list of items, where each item has the fields specified. Visually it can be shown as tabular data. Below is what some of this data might look like: | code | name | terms | |——|——|——-| |@ | Regular Settlement | Regular, Settlement | | C | Cash Settlement | Cash, Settlement | | N | Next Day Settlement | Next, Day, Settlement | | R | Seller Settlement | Seller, Settlement | | F | Intermarket Sweep | Intermarket, Sweep | | O | Opening Print | Opening, Print | | 4 | Derivative Priced | Derivative, Priced | | 5 | Re-Opening Print | Re-Opening, Print | | 6 | Closing Print | Closing, Print |
+<code>conditions_list</code> is a list of items, where each item has the fields specified. Visually it can be shown as tabular data. Below is what some of this data might look like:
 <code>terms</code> is clearly derived from <code>name</code>, the result of the inline expression. If the expression is non-trivial or not unconditionally true, then it does not belong in <code>model.txt</code>. If you are unsure if an expression improves the clarity of the model, leave it out.
@@ Line 211: / Line 237: @@
        AT_BID: The price is equal to the bid.
        BELOW_BID: The price is below the bid.</pre>
-<code>Definitions</code> is used to define a <code>TimeAndSale</code>. Each <code>TimeAndSale</code> has a set of properties associated with it: - <code>timestamp</code> - <code>price</code> - <code>size</code> - <code>condition</code> - <code>market_center</code> - <code>bbo_indicator</code>
+<code>Definitions</code> is used to define a <code>TimeAndSale</code>. Each <code>TimeAndSale</code> has a set of properties associated with it:
 <code>TimeAndSale</code> can be referenced elsewhere in the model.
-It is at the designer’s discretion whether to include a <code>Definitions</code> section or to provide the description inline where the term is used. The following heuristics are helpful in determining whether to place a definition in a <code>Definitions</code> section: - The term is referenced by multiple properties throughout the model - The definition is long or contains multiple levels of nesting which would impede the readability if included directly in the normal flow of the document When unsure, err on the side of putting the description inline rather than including a Definitions section.
+It is at the designer’s discretion whether to include a <code>Definitions</code> section or to provide the description inline where the term is used. The following heuristics are helpful in determining whether to place a definition in a <code>Definitions</code> section:
 <span id="styles"></span>
@@ Line 289: / Line 325: @@
 A default value is often declared. Where the data comes from is not specified (e.g. from a backend or a local file), that should be determined by the type of data and the application architecture.
-The following heuristic may be useful in determining whether property values belong in <code>Data</code> or <code>State</code>. It belongs in <code>Data</code> if: - The value can be modified by the user through interaction with the component - The value is read from an external source requiring real-time updates - There are obvious use-cases where external components will need to read or write to the value
+The following heuristic may be useful in determining whether property values belong in <code>Data</code> or <code>State</code>. It belongs in <code>Data</code> if:
 Otherwise, put the value in <code>State</code>.

← Older revision		Revision as of 15:01, 7 July 2026
Line 1:		Line 1:
−	~~<span id="model"></span>~~
−	~~= Model =~~
−
	User interfaces are composed of reusable semantic elements called components. Each component is specified by a set of documents: <code>model.txt</code>, <code>preview.xd</code>, <code>components.xd</code>, <code>layout.xd</code>, <code>user_flow.drawio</code>, and <code>use_cases.drawio</code>. This page covers the <code>model.txt</code> document.		User interfaces are composed of reusable semantic elements called components. Each component is specified by a set of documents: <code>model.txt</code>, <code>preview.xd</code>, <code>components.xd</code>, <code>layout.xd</code>, <code>user_flow.drawio</code>, and <code>use_cases.drawio</code>. This page covers the <code>model.txt</code> document.

Model - Revision history

Jon at 18:21, 7 July 2026

Jon at 15:01, 7 July 2026

Jon: Detailed description of `model.txt` and its usage within UI component specifications