The view tree is the runtime object containing a hierarchy of view nodes representing the service form relating to a service instance with domain data applied. The view tree can be thought of as representing the content for a service transaction. A view tree is stored against a service transaction as the viewTree property.

View Tree Content

The view tree has one root view node which can have children, each of which can also have zero or more children and so on, giving a hierarchical tree of view nodes – the view tree.

Also see the building the view tree section below for more details on which service form items are added to the view tree when it’s built, and the domain data and the view tree section below for more details regarding the way domain data impacts the view tree content.

See the sections directly below for more details around the content of a view tree for service transactions relating to web pages and those used for REST or SOAP API requests.

Web Page Requests

In terms of a service transaction being rendered as a web page via the application, the view tree represents what is displayed and how (i.e. look ‘n’ feel, editable or not, etc.) although the UI layer and widgets have a large bearing on the final display also. A service transaction view tree used for rendering a web page usually includes view node types both relating to domain data (e.g. repeater, record, attribute, etc. view node types) plus non-data types such as box, button, etc. view node types.

The view nodes within the view tree change on each request to reflect any changes applied via the UI. For example the following actions would all result in view nodes being updated and/or being added or removed from the view tree:

  • A new address record view node and related descendant view nodes (for e.g. attributes, buttons, standalone text, etc.) are added when the user selects to add a new address
  • An email attribute view node’s value changes when the user edits an email address field’s value
  • A new branch of view nodes are initialised within the view tree when an option relating to a group selector view node is selected
  • A button view node is made visible as it’s now deemed relevant after a value is entered in or an option is selected for a field
  • A role record view node and its descendant view nodes are all removed when the user selects to delete a director role they decided they no longer wanted
  • An attribute view node relating a ceased date has a date value set on it when the user ceases an existing director role

REST or SOAP API Requests

For REST or SOAP API requests the view tree is used to define/generate the payload content. This tends to mean only view node types relating to domain data are relevant, therefore view trees for service transactions relating to REST or SOAP API tend to have separate forms with leaner configuration compared to those used to render a web page.

However, even if certain non-data elements are contained within a service form used for a web service (e.g. a button element) – either because it was configured on a web service specific form, or the form has configuration shared by forms used for rendering as a web page – it doesn’t mean it will be included in the web service request content.

Like the UI layer and widgets for web pages, it’s the marshalling of the service transaction view tree into the web service payload that ultimately determines content for web service requests.

Building the View Tree

As mentioned in the view tree content section above, the view tree has a single view node as it’s root. When building a view tree this root view node is built based off the root element in the service form associated to the service transaction (via its serviceCode property) the view tree is being built for.

Once the root view node is built, child view nodes are then built based on any child elements of the root service form element, and the same for any child elements of those, etc. In this way the entire view tree is built by building the root view node then it’s children recursively.

This illustrates the close relationship between the service form and its service form item (SFI) elements and the view nodes within a service transactions’s view tree.

The exception as to whether a view node is built when a child SFI element is encountered in the service form are for record SFI elements. When record SFI elements are encountered as the service form is being parsed to build out the view tree, then a view node relating to it will only be created if there is domain data relating to it. Specifically:

  • A record element enclosed within a repeater element – the record view node will only be built if there is domain data relating to it (i.e. a domain name matching the record SFI’s domain attribute value). If more than one domain in the domain data matches, then a view node will be created per matching domain and added to the repeater node
  • A record element not enclosed within a repeater element – the record view node will always be created. If there is domain data relating to it (i.e. a domain name matching the record SFI’s domain attribute value then these details will be used for it). If no related domain data exists then an empty domain of that type/name will be initialised and referenced by the view node. If more than one domain in the domain data matches then the configuration is invalid and an error will occur. In most of these cases the solution is to enclose the record SFI element within a repeater SFI element, otherwise ensure multiple domain data is never created for service transactions that use a service form with this repeater-less record SFI configuration.


Building the view tree results in the following rule scopes being called:

  • instantiate – called on each view node after it is built
  • viewtree-initialise – called once the entire view tree after the building of the entire view tree has finished

See building a view node for details relating to an individual view node being built.

When is the View Tree Built?

Verne ensures the view tree is built and rebuilt as appropriate throughout the life cycle of a service instance and the service transaction or transactions that relate to it. Below are common actions that may be taken within the Verne system that result in the view tree being cleared or built or both.

User actionView tree actionRelated Verne command
User selecting a menu to start a new business service that creates new registry dataBuiltStartService
User selecting a menu to start a new business service that views or edits existing registry dataBuiltStartService
User saves and exists a service they are editingSaveCommit
User selects a saved service from their dashboard to continue editingRebuiltLoadCopy

Also see the platform archiving configuration options around clearing the view tree on a service transaction after a certain period.

The view tree can also be manually built on a service transaction at any time if it isn’t already using the service transaction build() method. It can be re-built on demand by setting the service transaction viewTree property to null before calling the build() method if desired. Having said that, explicitly calling for the view tree to be built should not be required given Verne manages the view tree as appropriate as already mentioned above so is stated here for completeness and advanced use only.

Domain Data and the View Tree

A service transaction contains all of the registry data relating to it including data created and maintained by previous service instances relating to the same registry data. A view tree on the other hand always pertains to a specific service instance, or, more specifically, a specific service transaction (the one it is stored against in the viewTree property). Also, while a service transaction contains the full registry data plus any service instance data, the view tree might only reflect a small portion of that data (it could even not relate to any domain data at all if desired).

The view tree uses the service form to provide its structure, and when elements relating to domain data are present the domain data for the service transaction also influences the resulting view tree. It’s also a two way street as events that result in changes to the view tree can also cause the domain data to change.

Some examples of view tree actions that alter domain data are:

  • building the view tree if a record element not enclosed by a repeater is present and the related domain doesn’t already exist in the domain data
  • setting/removing an attribute node’s value
  • adding/removing a child to a repeater node
  • making part of the view tree containing elements relating to domain data active/inactive e.g. via an update to a view node relating to a group selector element

Scenario 1: No Domain Data

For the first new service transaction relating to a new service instance for a business service that registers/creates new registry data, starting the service instance results in the service transaction domainTree being initialised as an empty domain. Then as the view tree is built using the service form, as record elements relating to a domain are encountered that need a view node to be built (i.e. not wrapped in a repeater element) then a domain is created and added to the service transaction’s domainTree (or serviceTree if contained within in a serviceInstance element).

In this way the domainTree and serviceTree can, and usually are, added to as the view tree is first built for a new service instance. Similarly if configuration run on building the view tree results in attribute view nodes having values set then these attribute values are also reflected in the relevant domain data.

Scenario 2: Existing Domain Data

When a view tree is built against a service transaction that already has existing domain data i.e. loading a saved service instance after a save and exit, or starting a new service instance that’s based on existing registry data (e.g. to edit or view etc.) then instead of the process of the view tree being built adding to the domain data, the reverse is true and the existing domain data impacts the view tree that is built. The exception is if the configuration has changed so a new record element or elements not within a repeater (as per scenario 1 above) exist, then the domain tree would be added to as a result of the view tree being built, as per scenario 1 above. Also, as per scenario 1 above, if the configuration run on building the view tree results in attribute view nodes having values updated then these attribute value changes are also reflected in the relevant domain data.

Examples

The following examples should help clarify these two scenarios mentioned above and the link between the service transaction’s domain data and its view tree and vice versa. In all cases the service form configuration is based on the same form snippet shown below and the business service configuration has been omitted for brevity, but assume it exists. Also the domain _id values are contrived to make things easier to follow and text keys have generally been left out other than one example whereas these would normally be specified on most elements.

Take a moment to absorb the following form configuration before moving on through the examples below. As a brief summary it’s a simple solar system that can include some planets and other celestial bodies (asteroids and/or comets), plus some other slightly contrived record elements used to illustrate a record’s behaviour when not enclosed within a repeater element.

<record shortCode="solarSystemDetails" domain="SolarSystem">
  <attribute attribute="Name" textKeyPrefix="solarSystem.name"/>
  <attribute attribute="ActiveYn" dataConstraint="yesNo">
    <platform:set-attribute-value scope="instantiate" when-attribute-value-empty="true" value="Y"/>
  </attribute>

  <record domain="Position">
    <attribute attribute="X"/>
    <attribute attribute="Y"/>
    <attribute attribute="Z"/>
  </record>

  <repeater shortCode="planets">
    <record domain="Planet">
      <attribute attribute="Name"/>
      <box shortCode="details">
        <attribute attribute="Diameter"/>
        <attribute attribute="Population"/>
      </box>

      <record domain="Composition">
        <attribute attribute="Material"/>
        <attribute attribute="MainColour"/>
        <attribute attribute="SolidYn"/>
      </record>

      <repeater shortCode="moons">
        <record domain="Moon">
          <attribute attribute="Name"/>
          <attribute attribute="Diameter" dataConstraint="long"/>
        </record>
      </repeater>
    </record>  
  </repeater>

  <repeater shortCode="otherCelestialBodies">
    <selector>
      <record domain="Asteroid">
        <attribute attribute="Name"/>
        <attribute attribute="Diameter"/>
      </record>

      <record domain="Comet">
        <attribute attribute="Name"/>
        <attribute attribute="LastSeen"/>
      </record>
    </selector>
  </repeater>

</record>

Example 1: A new service transaction for a new service instance not based on existing registry data

This is scenario 1 above. No registry data exists on which the new service instance should be based, so it’s a new service transaction with no existing domain data. So before the view tree is built the domainTree is initialised to consist of an empty SolarSytem domain, then the view tree is built.

viewTree XML:

<record code="solarSystemDetails" dn-id="d1" dn-name="SolarSystem">
  <attribute code="Name" ctl="V+RO-M-" attr-name="Name" dn-id="d1" textKeyPrefix="solarSystem.name"/>
  <attribute code="ActiveYn" ctl="V+RO-M-" attr-name="ActiveYn" dn-id="d1" attr-value="Y" dc-type="yesNo"/>
  <record code="Position" ctl="V+RO-M-" dn-id="d2" dn-name="Position">
    <attribute code="X" ctl="V+RO-M-" attr-name="X" dn-id="d2"/>
    <attribute code="Y" ctl="V+RO-M-" attr-name="Y" dn-id="d2"/>
    <attribute code="Z" ctl="V+RO-M-" attr-name="Z" dn-id="d2"/>
  </record>
  <repeater code="planets" ctl="V+RO-M-" min="0" paged="false"/>
  <repeater code="otherCelestialBodies" ctl="V+RO-M-" min="0" paged="false"/>
</record>

domainTree JSON:

{
  "_id": "d1",
  "name": "SolarSystem",
  "attributes": {
    "ActiveYn": "Y"
  },
  "children": [
    {
      "_id": "d2",
      "name": "Position"
    }
  ]
}

Points to note:

  • The text key configured against the solar system Name element appears in the view tree
  • The platform rule on the solar system ActiveYn element setting it to “Y” on instantiate (of the view node) resulted in the attribute being set on the domain
  • The solar system Position domain has been created as the corresponding record element was not enclosed in a repeater element
  • The attribute view nodes have all been created, although since they have no values they are not referenced in the domain data
  • The record elements within repeaters have not been created in the view tree and have not resulted in any related domain data being created
  • The view node code defaults to the domain name for record view nodes and the attribute name for attribute view nodes if no shortCode is specified on the SFI element it’s based on

Example 2: Adding a repeater record view node

Continuing on from example 1 above, let’s say we now click a button within the UI that results in a new planet being added to the planets repeater.

viewTree XML:

<record code="solarSystemDetails" dn-id="d1" dn-name="SolarSystem">
  <attribute code="Name" ctl="V+RO-M-" attr-name="Name" dn-id="d1" textKeyPrefix="solarSystem.name"/>
  <attribute code="ActiveYn" ctl="V+RO-M-" attr-name="ActiveYn" dn-id="d1" attr-value="Y" dc-type="yesNo"/>
  <record code="Position" ctl="V+RO-M-" dn-id="d2" dn-name="Position">
    <attribute code="X" ctl="V+RO-M-" attr-name="X" dn-id="d2"/>
    <attribute code="Y" ctl="V+RO-M-" attr-name="Y" dn-id="d2"/>
    <attribute code="Z" ctl="V+RO-M-" attr-name="Z" dn-id="d2"/>
  </record>
  <repeater code="planets" ctl="V+RO-M-" min="0" paged="false">
    <record code="Planet" ctl="V+RO-M-" dn-id="d3" dn-name="Planet">
      <attribute code="Name" ctl="V+RO-M-" attr-name="Name" dn-id="d3" attr-value="Earth"/>
      <box code="details" ctl="V+RO-M-">
        <attribute code="Diameter" ctl="V+RO-M-" attr-name="Diameter" dn-id="d3" attr-value="12,742"/>
        <attribute code="Population" ctl="V+RO-M-" attr-name="Population" dn-id="d3" attr-value="7,530,000,000"/>
      </box>
      <record code="Composition" ctl="V+RO-M-" dn-id="d4" dn-name="Composition">
        <attribute code="Material" ctl="V+RO-M-" attr-name="Material" dn-id="d4"/>
        <attribute code="MainColour" ctl="V+RO-M-" attr-name="MainColour" dn-id="d4"/>
        <attribute code="SolidYn" ctl="V+RO-M-" attr-name="SolidYn" dn-id="d4"/>
      </record>
      <repeater code="moons" ctl="V+RO-M-" min="0" paged="false"/>
    </record>
  </repeater>
  <repeater code="otherCelestialBodies" ctl="V+RO-M-" min="0" paged="false"/>
</record>

domainTree JSON:

{
  "_id": "d1",
  "name": "SolarSystem",
  "attributes": {
    "ActiveYn": "Y"
  },
  "children": [
    {
      "_id": "d2",
      "name": "Position"
    },
    {
      "_id": "d3",
      "name": "Planet",
      "children": [
        {
          "_id": "de4",
          "name": "Composition"
        }
      ]
    }
  ]
}

Points to note:

  • The Planet domain was added to the domain data as a result of the record view node being added to the view tree
  • The planet’s Composition domain has also been created as the corresponding child record element was not enclosed in a repeater element
  • The box and attribute view nodes relating to the planet view node have been created

Example 3: Adding a repeater selector view node

Continuing on from example 2 above, now let’s say we now click a button within the UI that results in a new comet being added to the otherCelestialBodies repeater.

viewTree XML:

<record code="solarSystemDetails" dn-id="d1" dn-name="SolarSystem">
  <attribute code="Name" ctl="V+RO-M-" attr-name="Name" dn-id="d1" textKeyPrefix="solarSystem.name"/>
  <attribute code="ActiveYn" ctl="V+RO-M-" attr-name="ActiveYn" dn-id="d1" attr-value="Y" dc-type="yesNo"/>
  <record code="Position" ctl="V+RO-M-" dn-id="d2" dn-name="Position">
    <attribute code="X" ctl="V+RO-M-" attr-name="X" dn-id="d2"/>
    <attribute code="Y" ctl="V+RO-M-" attr-name="Y" dn-id="d2"/>
    <attribute code="Z" ctl="V+RO-M-" attr-name="Z" dn-id="d2"/>
  </record>
  <repeater code="planets" ctl="V+RO-M-" min="0" paged="false">
    <record code="Planet" ctl="V+RO-M-" dn-id="d3" dn-name="Planet">
      <attribute code="Name" ctl="V+RO-M-" attr-name="Name" dn-id="d3" attr-value="Earth"/>
      <box code="details" ctl="V+RO-M-">
        <attribute code="Diameter" ctl="V+RO-M-" attr-name="Diameter" dn-id="d3" attr-value="12,742"/>
        <attribute code="Population" ctl="V+RO-M-" attr-name="Population" dn-id="d3" attr-value="7,530,000,000"/>
      </box>
      <record code="Composition" ctl="V+RO-M-" dn-id="d4" dn-name="Composition">
        <attribute code="Material" ctl="V+RO-M-" attr-name="Material" dn-id="d4"/>
        <attribute code="MainColour" ctl="V+RO-M-" attr-name="MainColour" dn-id="d4"/>
        <attribute code="SolidYn" ctl="V+RO-M-" attr-name="SolidYn" dn-id="d4"/>
      </record>
      <repeater code="moons" ctl="V+RO-M-" min="0" paged="false"/>
    </record>
  </repeater>
  <repeater code="otherCelestialBodies" ctl="V+RO-M-" min="0" paged="false">
    <selector code="item1" ctl="V+RO-M-" current-selection="Comet" current-selected-dn-id="d5">
      <record code="Comet" ctl="V+RO-M-" dn-id="d5" dn-name="Comet">
        <attribute code="Name" attr-name="Name" ctl="V+RO-M-" dn-id="d5"/>
        <attribute code="LastSeen" attr-name="LastSeen" ctl="V+RO-M-" dn-id="d5"/>
      </record>
    </selector>
  </repeater>
</record>

domainTree JSON:

{
  "_id": "d1",
  "name": "SolarSystem",
  "attributes": {
    "ActiveYn": "Y"
  },
  "children": [
    {
      "_id": "d2",
      "name": "Position"
    },
    {
      "_id": "d3",
      "name": "Planet",
      "children": [
        {
          "_id": "de4",
          "name": "Composition"
        }
      ]
    },
    {
      "_id": "d5",
      "name": "Comet"
    }
  ]
}

Points to note:

  • The Comet domain was added to the domain data as a result of the record view node being added to the view tree
  • The configuration relating to the comet record in the service form has been used to create the comet view node structure, not the asteroid also configured within the selector
  • The view tree has a selector element as the direct child of the otherCelestialBodies repeater element although the domain data has no instance of this selector, only the domain

Example 4: Adding a more record nodes

Continuing on from example 3 above, just to fill the form out a bit let’s jump ahead having performed actions within the UI that result in the following:

  • Another new planet being added to the planets repeater with a Name of “Mars”
  • A new asteroid being added to the otherCelestialBodies repeater
  • Another new comet being added to the otherCelestialBodies repeater with a Name attribute of “Halley’s Comet”
  • The original planet’s Name set to “Earth”, Diameter to “12,742”, Population to “7,530,000,000” and a moon being added to the moon repeater with a Name of “The moon” and a Diameter of 3,474.2

viewTree XML:

<record code="solarSystemDetails" dn-id="d1" dn-name="SolarSystem">
  <attribute code="Name" ctl="V+RO-M-" attr-name="Name" dn-id="d1" textKeyPrefix="solarSystem.name"/>
  <attribute code="ActiveYn" ctl="V+RO-M-" attr-name="ActiveYn" dn-id="d1" attr-value="Y" dc-type="yesNo"/>
  <record code="Position" ctl="V+RO-M-" dn-id="d2" dn-name="Position">
    <attribute code="X" ctl="V+RO-M-" attr-name="X" dn-id="d2"/>
    <attribute code="Y" ctl="V+RO-M-" attr-name="Y" dn-id="d2"/>
    <attribute code="Z" ctl="V+RO-M-" attr-name="Z" dn-id="d2"/>
  </record>
  <repeater code="planets" ctl="V+RO-M-" min="0" paged="false">
    <record code="Planet" ctl="V+RO-M-" dn-id="d3" dn-name="Planet">
      <attribute code="Name" ctl="V+RO-M-" attr-name="Name" dn-id="d3" attr-value="Earth"/>
      <box code="details" ctl="V+RO-M-">
        <attribute code="Diameter" ctl="V+RO-M-" attr-name="Diameter" dn-id="d3" attr-value="12,742"/>
        <attribute code="Population" ctl="V+RO-M-" attr-name="Population" dn-id="d3" attr-value="7,530,000,000"/>
      </box>
      <record code="Composition" ctl="V+RO-M-" dn-id="d4" dn-name="Composition">
        <attribute code="Material" ctl="V+RO-M-" attr-name="Material" dn-id="d4"/>
        <attribute code="MainColour" ctl="V+RO-M-" attr-name="MainColour" dn-id="d4"/>
        <attribute code="SolidYn" ctl="V+RO-M-" attr-name="SolidYn" dn-id="d4"/>
      </record>
      <repeater code="moons" ctl="V+RO-M-" min="0" paged="false">
        <record code="Moon" ctl="V+RO-M-" dn-id="d10" dn-name="Moon">
          <attribute code="Name" ctl="V+RO-M-" attr-name="Name" dn-id="d10" attr-value="The Moon"/>
          <attribute code="Diameter" ctl="V+RO-M-" attr-name="Diameter" dn-id="d10" dc-type="long" attr-value="3474.2"/>
        </record>
      </repeater>
    </record>
    <record code="Planet" ctl="V+RO-M-" dn-id="d6" dn-name="Planet">
      <attribute code="Name" ctl="V+RO-M-" attr-name="Name" dn-id="d6" attr-value="Mars"/>
      <box code="details" ctl="V+RO-M-">
        <attribute code="Diameter" ctl="V+RO-M-" attr-name="Diameter" dn-id="d6"/>
        <attribute code="Population" ctl="V+RO-M-" attr-name="Population" dn-id="d6"/>
      </box>
      <record code="Composition" ctl="V+RO-M-" dn-id="d7" dn-name="Composition">
        <attribute code="Material" ctl="V+RO-M-" attr-name="Material" dn-id="d7"/>
        <attribute code="MainColour" ctl="V+RO-M-" attr-name="MainColour" dn-id="d7"/>
        <attribute code="SolidYn" ctl="V+RO-M-" attr-name="SolidYn" dn-id="d7"/>
      </record>
      <repeater code="moons" ctl="V+RO-M-" min="0" paged="false"/>
    </record>
  </repeater>
  <repeater code="otherCelestialBodies" ctl="V+RO-M-" min="0" paged="false">
    <selector code="item1" ctl="V+RO-M-" current-selection="Comet" current-selected-dn-id="d5">
      <record code="Comet" ctl="V+RO-M-" dn-id="d5" dn-name="Comet">
        <attribute code="Name" attr-name="Name" ctl="V+RO-M-" dn-id="d5"/>
        <attribute code="LastSeen" attr-name="LastSeen" ctl="V+RO-M-" dn-id="d5"/>
      </record>
    </selector>
    <selector code="item1" ctl="V+RO-M-" current-selection="Asteroid" current-selected-dn-id="d8">
      <record code="Asteroid" ctl="V+RO-M-" dn-id="d8" dn-name="Asteroid">
        <attribute code="Name" ctl="V+RO-M-" attr-name="Name" dn-id="d8"/>
        <attribute code="Diameter" ctl="V+RO-M-" attr-name="Diameter" dn-id="d8"/>
      </record>
    </selector>
    <selector code="item1" ctl="V+RO-M-" current-selection="Comet" current-selected-dn-id="d9">
      <record code="Comet" ctl="V+RO-M-" dn-id="d9" dn-name="Comet">
        <attribute code="Name" ctl="V+RO-M-" attr-name="Name" dn-id="d9" attr-value="Halley's Comet"/>
        <attribute code="LastSeen" ctl="V+RO-M-" attr-name="LastSeen" dn-id="d9"/>
      </record>
    </selector>
  </repeater>
</record>

domainTree JSON:

{
  "_id": "d1",
  "name": "SolarSystem",
  "attributes": {
    "ActiveYn": "Y"
  },
  "children": [
    {
      "_id": "d2",
      "name": "Position"
    },
    {
      "_id": "d3",
      "name": "Planet",
      "children": [
        {
          "_id": "de4",
          "name": "Composition"
        },
        {
          "_id": "de10",
          "name": "Moon",
          "attributes": {
            "Name": "The Moon",
            "Diameter": 3474.2
          }
        }
      ]
    },
    {
      "_id": "d6",
      "name": "Planet",
      "attributes": {
        "Name": "Mars"
      },
      "children": [
        {
          "_id": "de7",
          "name": "Composition"
        }
      ]
    },
    {
      "_id": "d5",
      "name": "Comet"
    },
    {
      "_id": "d8",
      "name": "Asteroid"
    },
    {
      "_id": "d9",
      "name": "Comet",
      "attributes": {
        "Name": "Halley's Comet"
      }
    }
  ]
}

Points to note:

  • The configuration relating to the asteroid record in the service form has been used to create the asteroid view node structure, not the comet also configured within the selector
  • The Moon domain is a sibling to the Composition domain in the domain data i.e. they are both direct children of the Planet domain even though they are nested at different levels within the view tree

Example 5: Loading in a saved service instance

Continuing on from example 4 above, let’s say we saved and exited the service instance at this point, then loaded the saved service instance from our dashboard for further editing. As mentioned in the section above regarding when the view tree is built the load from the dashboard will result in the view tree being rebuilt (technically the view tree will be built on a new service transaction created as a result of the life-cycle load-copy command but that’s needless detail for this illustration as the resulting view tree would be the same).

This is scenario 2 above. In this case the viewTree and domainTree on the newly loaded service transaction would be the same as they were in example 4 above.

Example 6: A new service instance based on existing registry data

Example 5 above applies equally if instead of loading a saved service instance from the dashboard it was an activated service instance and we started a new maintain or view service instance based on the applied registry data as long as the new service instance related to service form configuration that exactly matched the service form configuration used for the service instance that was activated. In this case the viewTree and domainTree for the newly loaded maintain or view service instance would still match those from example 4 above. This is the other flavour of scenario 2 (above) involved existing registry data.

However, new maintain or view service instances are usually based on a business service that relates to service form configuration that differs from the service form that was used to create it. It doesn’t have to of course, but it’s usually the case. This example highlights this common case.

So let’s say we start a new maintain service instance based on the service instance referenced in example 4 (or 5) above being activated in its current state. And instead of the service form configuration snippet used for all of the examples above, let’s say the new maintain service instance relates to service form configuration based on the form snippet below. Note some more complex rule configuration has also been introduced in this snippet to illustrate how this impacts the view tree.

<record shortCode="solarSystemMaintainPlanetDetails" domain="SolarSystem">
  <attribute attribute="Name" textKeyPrefix="solarSystem.name" readOnly="true"/>

  <repeater shortCode="planets">
    <record domain="Planet">
      <attribute attribute="Name" readOnly="false">
        <platform:set-property readOnly="true"/>
      </attribute>
      <attribute attribute="Diameter"/>
      <attribute attribute="Population">
        <platform:set-property scope="instantiate,change" target="vpath" path="./*[type=button][name=extinction]" visible="false" when-attribute-value-empty="true"/>
        <platform:set-property scope="change" target="vpath" path="./*[type=button][name=extinction]" visible="true" when-attribute-value-empty="false"/>
      </attribute>
      <button shortCode="extinction" visible="false">
        <rule scope="click" reference="planet.extinctionEvent"/>
      </button>

      <record domain="Composition">
        <attribute attribute="Material"/>
        <attribute attribute="MainColour"/>
        <attribute attribute="SolidYn"/>
      </record>

      <repeater shortCode="moons">
        <record domain="Moon">
          <attribute attribute="Name"/>
          <attribute attribute="Diameter" dataConstraint="long"/>
        </record>
      </repeater>
    </record>  
  </repeater>
</record>

Once started, the new maintain service transaction details domainTree would be as per example 4 (or 5) above as the data has not changed (yet), but the viewTree would look quite different as shown below.

viewTree XML:

<record code="solarSystemMaintainPlanetDetails" dn-id="d1" dn-name="SolarSystem">
  <attribute code="Name" ctl="V+RO+M-" attr-name="Name" dn-id="d1" textKeyPrefix="solarSystem.name"/>
  <repeater code="planets" ctl="V+RO-M-" min="0" paged="false">
    <record code="Planet" ctl="V+RO-M-" dn-id="d3" dn-name="Planet">
      <attribute code="Name" ctl="V+RO+M-" attr-name="Name" dn-id="d3" attr-value="Earth"/>
      <attribute code="Diameter" ctl="V+RO-M-" attr-name="Diameter" dn-id="d3" attr-value="12,742"/>
      <attribute code="Population" ctl="V+RO-M-" attr-name="Population" dn-id="d3" attr-value="7,530,000,000"/>
      <button code="extinction" ctl="V+RO-M-"/>
      <record code="Composition" ctl="V+RO-M-" dn-id="d4" dn-name="Composition">
        <attribute code="Material" ctl="V+RO-M-" attr-name="Material" dn-id="d4"/>
        <attribute code="MainColour" ctl="V+RO-M-" attr-name="MainColour" dn-id="d4"/>
        <attribute code="SolidYn" ctl="V+RO-M-" attr-name="SolidYn" dn-id="d4"/>
      </record>
      <repeater code="moons" ctl="V+RO-M-" min="0" paged="false">
        <record code="Moon" ctl="V+RO-M-" dn-id="d10" dn-name="Moon">
          <attribute code="Name" ctl="V+RO-M-" attr-name="Name" dn-id="d10" attr-value="The Moon"/>
          <attribute code="Diameter" ctl="V+RO-M-" attr-name="Diameter" dn-id="d10" dc-type="long" attr-value="3474.2"/>
        </record>
      </repeater>
    </record>
    <record code="Planet" ctl="V+RO-M-" dn-id="d6" dn-name="Planet">
      <attribute code="Name" ctl="V+RO+M-" attr-name="Name" dn-id="d6" attr-value="Mars"/>
      <attribute code="Diameter" ctl="V+RO-M-" attr-name="Diameter" dn-id="d6"/>
      <attribute code="Population" ctl="V+RO-M-" attr-name="Population" dn-id="d6"/>
      <button code="extinction" ctl="V-RO-M-"/>
      <record code="Composition" ctl="V+RO-M-" dn-id="d7" dn-name="Composition">
        <attribute code="Material" ctl="V+RO-M-" attr-name="Material" dn-id="d7"/>
        <attribute code="MainColour" ctl="V+RO-M-" attr-name="MainColour" dn-id="d7"/>
        <attribute code="SolidYn" ctl="V+RO-M-" attr-name="SolidYn" dn-id="d7"/>
      </record>
      <repeater code="moons" ctl="V+RO-M-" min="0" paged="false"/>
    </record>
  </repeater>
</record>

Points to note:

  • The solar system’s Name attribute view node is read-only (RO+) due to the attribute on the relevant attribute element in the form
  • The planet’s Name attribute view node is read-only (RO+) due to the runtime rule on the relevant attribute element in the form even though the element has a readOnly attribute set to false (i.e. the rule overrides view node property initially based on the form item element)
  • The Earth planet’s extinction button is visible (V+) due to the runtime rule on the Population attribute element which has a value, even though the button element has a visible attribute set to false (i.e. the rule overrides view node property initially based on the form item element)
  • The non-Earth planet’s extinction button is invisible (V–) due to the runtime rule on the Population attribute element which does not have a value
  • The rule elements are not present in the view tree, only their impacts are (if any) i.e. the property set based on them, etc.
  • The planet view node structure differs from the examples above i.e. no details box and has a button view node
  • Only the domain data relating to the elements in the form snippet are included in the view tree
0
0
Previous
Domain Tree
Next
View Node

Jump to Section