Guideline for using Deon Digital’s GUI¶
Deon Digital’s GUI allows users to write and evaluate contracts by using the contract specification language. A contract written in Deon Digital’s CSL is a textual specification of allowed sequences of actions (events) which multiple parties are expected to perform in order to fulfill a contract. The GUI displays the node name and ledger type as well as links to relevant documentation such as our guidelines about the API, the language and the changelog. The GUI exposes three interactions with the Deon application platform:
In the following sections, we will discuss each of these in detail:
Within the composer, the user has the opportunity to press “Save Declaration” or “Instantiate Contract”. “Save Declaration” will use the “Declaration Name” field. The user can reuse saved declarations later by using the “Choose Declaration” dropdown at the top of the page.
“Instantiate Contract” both saves the declaration and instantiates a contract on the ledger using the information from the remaining fields. The “Contract Name” field specifies the name of the contract instance, and can be chosen freely by the user. The peers that are part of the contract network have to be defined as well. The “peers” dropdown is populated by the available peers on the network on which data can be stored and where contracts can be executed. The entry point defines the name of the starting contract. This name must refer to a contract in the CSL and specifies which contract is executed first. If a contract accepts input parameters, they must be specified in the correct order with type and value. Once the contract is instantiated, the data is stored on the ledger which is distributed. The distribution on the network happens automatically.
The viewer lets the user see the contract specification language (CSL) and the abstract syntax tree (AST) for each instantiated contract. In this example, the contract “Bike Sale” has been choosen:
By selecting the CSL tab, the user can see the individual contract declaration, the residual contract which specifies the still remaining events, as well as the list of past events that have successfully been submitted to the contract so far. The user can create events by pressing “Create Event” at the bottom of the viewer page. Events can also be applied in the Actions tab.
By selecting the AST tab, a graphic visualisation of the structure of the residual contract is provided.
Based on the actual state of the contract, event types can be executed within the actions tab at the given time. The never changing ID (instantiating a contract creates a new ID for every instantiation), the never changing declaration ID (forever attached to an instantiated contract), the name, the event, the agent and the expression are visible for each expected event. Based on the specification of the contract, specific events can be added to each event type.
The examination of the contracts can be done by using the value expression language. Report expressions are either evaluated within the context of a specific contract, or without context. The latter can be done by selecting “Independently” in the drop down menu. Reports can be given value arguments with the dropdown menus in the bottom. Pressing “Run” causes the system to execute the operation and display the result at the bottom of the page.
More practical examples about how contracts can be specified are mentioned here.