Entity property editor [unfocused]: nested templates for composite entities with composite key members.

[01es]

Description

Current support for displayAs templates support only the first level composite key members. Please refer to the original issue https://github.com/fieldenms/tg/issues/1175.

In cases where any of the composite key members are composite themselves, their values are rendered using template z (this happens automatically due to toString representation of composite keys). The template functionality needs to be enriched to support expressions that could define templates at any level of nesting.

Two alternative notations have been considered:

• [ ] 1. Dot-expression, where sub-members of composite key members can be referred to by indices, separated with .. For example the first sub-member of the first composite key member could be referred to as #1.1, second sub-member – #1.2.

  A couple of complete template examples: #1.1tv#1.2tv#2tv, #1.1tv#2tv#1.2tv.

  Pros: this notation is aligned with dot-expressions for property paths, used in the application code, which would feel "natural" and therefore easier to understand, with the only difference of using indices instead of property names.

  Cons: More verbose in case of a complex nested structure due to the need to express complete paths to every sub-member. Potentially less expressive. For example, there is no natural way to provide a shorthand to define inlining of sub-members for a composite key member, equivalent in nature to the default "" at the first level (i.e., a key member would be rendered as its sub-member values with template #itv). Please refer to item 2 below to see how this can be expressed in case of the bracketed notation.

• [ ] 2. Bracket-expression, where the templates for nested levels are demarcated with square brackets[ ]. The basic form for such templates would be #i[template].

  A couple of complete template examples, equivalent to those used in item 1: #1[#1tv#2tv]#2tv, #1[#1tv]#2tv#1[#2tv].

  Pros: more terse expressions without repetitions for nested templates. Ability to support default and z templates for nested levels. For example, #1[]#2tv that would be equivalent to #1[#1tv#2tv]#2tv, or #1[z]#2tv that would be equivalent to #1tv#2tv.

  Cons: A new syntax to express property paths. Potentially more verbose in cases where order and levels of are mixed. For example, #1.1tv#2.1tv#1.2tv#2.2tv vs #1[#1tv]#2[#1tv]#1[#2tv]#2[#2tv].

Only one of the notations needs to be implemented.

Expected outcome

Ability to define displayAs for nested levels of composite entities with key members that are themselves composite entities.