Uploaded image for project: 'Identity Gateway'
  1. Identity Gateway
  2. OPENIG-4782

Learn how platform UI have realized trees, UI/backend relationship

    Details

    • Type: Task
    • Status: Resolved
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: Not Applicable
    • Fix Version/s: Not Applicable
    • Component/s: UI - Freeform Editor
    • Labels:
      None
    • Epic Link:
    • Sprint:
      2020.10 - IG / Microservices
    • Story Points:
      2

      Description

      Overview

      The platform UI tree behaviour seems to be a fairly faithful port to Vue of the trees in AM.

      The UI/backend relationship appears to be that all persistent information lives within the backend at least at some stage of its lifecycle. When a tree page is opened for a specific tree, the UI makes rest requests to the AM tree api for the available nodes (to display in the column to the left), and for the nodes that should be displayed in the current tree. The responses to these requests detail even UI specific information such as x/y positions, but also the connections the nodes have in the UI.

       

      When a node is either dragged to the editor, or clicked to be edited, the UI makes several requests for further information. For an existing node, It requests the schema to use in creating the edit form for the node, as well as the current data to use for that node. For a new node it also requests the 'template' to use for the initial data of the node.

       

      Tree information is sent back to the server when the save button is clicked, at which point the data for any altered nodes, as well as the model for the tree are both sent.

       References between nodes and other objects

      One subject that came up when IG first discussed how we would adopt an approach based on dynamically constructed forms was how to handle references from one node/object to another that may not be visible in the UI. In the platform tree UI one such node is the 'Inner Tree Evaluator' node, which routes data through another tree. The node presents a form that has a select input where the user can choose from the names of the other existing trees, the data for which being supplied by REST request. There is no reason to assume that a similar approach couldn't be used for IG with the AM service - where if one is already 'saved' then the REST request would supply its name as part of a list, and any instances which had not yet been saved could be added to the list of entries by the UI.

      Validation

      Validation seems to occur both in the UI based on rules supplied as part of the json schema for a node, and by the backend - with the UI receiving 400 responses when the save button is clicked and invalid config is present (the UI seems to try saving each altered node in turn before saving the route, and stopping at the first failed save, displaying the message returned from the server to the user).

      Useful information:

      AM documentation on node development, that mentions the classes and interfaces used, with links to the relevant javadocs: https://ea.forgerock.com/docs/am/auth-nodes/core-class.html

       

        Attachments

          Activity

            People

            • Assignee:
              dave.ernsting Dave Ernsting
              Reporter:
              guillaume.sauthier Guillaume Sauthier
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: