A view node can be thought of as a runtime object representation based on a service form item (SFI) XML element. View nodes only exist within a service transaction’s view tree.

It is important to understand however that a view node is a runtime object, whereas the service form item on which is was based is static. See the section below on how view nodes can diverge from the service form item on which is was based for further details.

See the view tree documentation for more details around how view nodes are built when the view tree is, or via user or system actions performed against the view tree.

Tip For service form item (SFI) level rules, the view node is available as the viewNode variable.

View Node Types

View nodes have a type property that typically reflects the SFI element on which it was based. There’s nothing stopping a view node type being set to something other than the SFI element type on which it was based, but this is what Verne does by design to keep things clearer. Just noting that this isn’t a requirement is enough to suffice for now before going back to thinking of the view node type as the SFI element type the view node relates to.

A view node can be based on any one of the following service form item (SFI) types and reflects the view node type values. In each case a view node of a given type is based on an SFI of the same name (although the remaining view node properties are only fully resolved at runtime as per the section on view nodes beyond the SFI below):

The following SFI types do not have view node representation as they do not make sense as a view node in a runtime context:

  • form fragment – resolves into the SFIs contained within the fragment at runtime
  • slot – resolves into SFIs defined by the slot at runtime
  • component – resolves into the SFIs defined within the component runtime
  • text key – too low level, text key SFIs instead belong to a parent view node

Container View Nodes

Some view node types are considered container view nodes, in that they can contain other view nodes as they’re children. They can also be split into two categories of those relating to domain data and those not, as follows:

  • Container types – view nodes that are associated with some form of domain data, whether it be domain control, a domain itself or a domain attribute. View node types that relate to domain data are:
    • repeater – holds zero or more record view nodes or selector view nodes
    • serviceInstance – relates to the service transaction serviceTree root domain
    • record – relates to a domain within the service transaction domainTree (or serviceTree if it has a serviceInstance record view node as an ancestor)
    • selector – can have no children or exactly one record view node
    • box – holds zero or more record view nodes or selector view nodes
  • Non-container types – view nodes that cannot contain other view nodes as children are. These are all view node types not listed as container types above, but for completeness they are:
    • attribute
    • instanceAttribute
    • text
    • button
    • menu

Domain Data & View Nodes

View node types can also be split into two categories of those relating to domain data and those not, as follows:

  • Domain data types – view nodes that are associated with some form of domain data, whether it be domain control, a domain itself or a domain attribute. View node types that relate to domain data are:
    • repeater – holds zero or more record view nodes or selector view nodes
    • serviceInstance – relates to the service transaction serviceTree root domain
    • record – relates to a domain within the service transaction domainTree (or serviceTree if it has a serviceInstance record view node as an ancestor)
    • selector – can have no children or exactly one record view node
    • attribute – relates to an attribute belonging to a domain within the service transaction domainTree. The domain will be the one referenced by the first record view node in its ancestors
    • instanceAttribute – relates to an attribute belonging to a domain within the service transaction serviceTree. The domain will be the one referenced by the parent record view node in its ancestors
  • Non-data types – view nodes that are independent of domain data i.e. they don’t influence or are influence by domain data. These are all view node types not listed as domain data types above, but for completeness they are:
    • box
    • text
    • button
    • menu

See domain data and the view tree for details and examples of how domain data impacts whether a related view node is built and vice versa.

View Nodes Beyond Service Form Items (SFIs)

Whilst a view node is based on an SFI, it does not mean it will reflect the properties specified on that SFI. For example, you could have the following SFI confgiuration:

<attribute attribute="Attribute1" readOnly="true" textKeyPrefix="attribute1"/>

This does not mean that a view node based off this SFI will necessarily have a readOnly property of true, or that it may not have other properties set such as being invisible, or have key values associated to it, all of which are not specified in the SFI configuration. Why it that?

Because view nodes are runtime objects, subject to rules and other configuration that may not be on the SFI but still impact the resulting view node’s state.

Similarly, some view node types are subject to domain data which gives them values (e.g. attribute view nodes) or determines whether they’re built or not (e.g. record view nodes).

Remember A view node is based on a service form item (SFI), but it’s properties and state can be vastly different as a result of runtime rules and related domain data if applicable.
Note It’s the configuration pertaining to the SFI as represented in the service form that the view node is based on, not the SFI form configuration (if different).

Building a View Node

As mentioned in build the view tree, each view node is built based off an element within the service form, then any rules associated to the element are processed against the view node.

Building a view node results in the following rule scopes being called:
  • instantiate – called on the view node after it is built; or once it is made active if inactive when built (see section below)
  • viewtree-initialise – called on each view node after the entire view tree has finished being built

Instantiating Inactive View Nodes

The exception to the rule scopes mentioned in the section above being called when a view node is built is if the view node is inactive. If a view node is inactive then rules are not run on it, as outlined by the active property, which even applies to the instantiate and viewtree-initialised rule scopes when a view node is built. This could mean important rules would be missed for view nodes that are inactive when first built but are later made active, which could lead to unstable application behaviour.

The instantiated property is used to mitigate against these rule scopes being missed. This is done by this property only being set to true once the instantiate rule scope has been called against a view node. Inversely, the instantiate rule scope is called against a view node when it is made active if the instantiated property is not set to true already. This means the instantiate rules are still only ever run once on a view node, although this is when the view node is first made active if it was inactive when it was first built.

When is a View Node Built?

Most view nodes are built whenever the view tree is built. There are some exceptions though, where the view tree already exists and then new view nodes are added. This typically relates to a child view node being added to repeater view node types. See the repeaterAddChild method for more details although these actions are usually triggered via calls from the UI layer and do not need to be handled from a configuration perspective, other than the awareness that repeater child view nodes can be be built when added rather than when the view tree is built.

To understand the implementation see CatDocs.

0
0
Previous
View Tree
Next
Validation

Jump to Section