Data Form Types
A data form also supports a set of views. Each of these views is made up of cards. A card represents a UX control that we will link to a data source - or embed within another Card.
The cards provide us a flexible way to provide reusable form components that can be laid out in rows and flex grids and then hooked to data sources.
This is in place to allow us to define types of card that we can use to build up a simple form presentation. For example, the starting set of card types are:
Name | Description | Properties |
---|---|---|
row | Adds a row DIV for the data form allowing you to group child cards in a flex layout | N/A |
attributeEditor | Shows an editor control for the given taxon based on the current data object. The type of control is based on the taxon’s properties. | path - The path of the taxon we will be showing class - an object of key/value that will be used for CSS classes on the control (useful with height, width etc.) height - used to set the style height for the editor width - used to set the style width for the editor showImagePreview - used to show the image/snippet of the data that needs reviewing |
dataForm | Allows the creation of a new data form, and moves the focus from the current data object (each form is based on a single data object) to the data object child instance (based on the path) provided | path - The path of the taxon we will be showing the child instances of data objects based on (ie. DataObject/DataAttribute) |
banner | The top section of the page that provides a place for the title, description and logo. | title - this refers to the title of the page description - this holds the additional information about the page icon - used to set the icon |
button | Allows the creation of button | color - used to set color of the button label - the label of the button action - used to set what action should the button perform when it is clicked sourceId - identifies the data source to execute the method on additionalPayload - copies the document family to the data form method - name of the method to implement after action has been taken |
groupBox | Adds a container to group the related fields | N/A |
table | Allows the creation of table | path - the name of the taxon we will be showing height - used to set the height of the table |
expansionPanel | Displays the form in a list of expandable items | N/A |
informationCallout | Provides a notification on the number of objects or attributes found by the logic | N/A |
> We would create a Vuex store to represent a Data Form. This would allow us to have a single way for all the cards and data sources to be referenced and provide a single point of interaction. Much like our document Vuex, we will need to allow multiple instances of this store, in case we want to have two forms up in the UX. | ||
Data Form
This type of card represent the base of a form for a specific data object. You imagine we have Data Object, then we would want to have a card that is of type dataForm, and has a path of DataObject.
The children of this card would then typically either
- Layout other cards
- Present a data attribute that is a child of DataObject
- Present another dataForm that is a child data object of DataObject (such as ChildDataObject).
So in order to layout a data form, we would use a combination of Layout Cards, Data Attribute cards (type path), pointing to a data attribute and Data Forms card to embed child data objects into the form.
Using Cards to Provide Flexibility
The actual cards in the platform (Java/Python code) are just metadata objects with no functionality, however as we think about how to layout a dynamic data form we will want to consider what additional attribute we might want to apply to the card to provide flexibility in the layout of the data form.
For example:
- Imagine that we want to provide a way for a user to simply press “Enter” to remove a status. This requirement is quite specific to user configuration, therefore if we wanted to have that we might want to include a setting on the path card (such as clearOnEnter=true) and use that in the UI. This will allow us to take the custom requirements and expose them in the data form and card metadata to drive the functionality of the data forms for customer engagements.
- As we move through the build out of Data Forms, we also want to consider other “views” of the data. For example in ChildDataObject as a child data form of DataObject, we might not want to have a form with fields but instead be presented as a grid. In this case we would want to add a new “type” of card (say dataGrid) and then provide that to the UI and thus in the UI extend the available controls.
Defining a Data Form is YAML
You can define and publish a Data Form to the platform using YAML. A working example of the target structure is below.
orgSlug: org
slug: demo-card
version: 1.0.0
type: dataForm
name: Demo
taxon: DataObject
dataSources:
- id: 23894u238o471
name: DataObject
implementation: simpleDataObject
views:
- id: 29834u7238947
name: DataObject View
cards:
- type: row
children:
- type: attributeEditor
properties:
# These are the CSS classes to apply
class:
pa-2: true
# This is the name of the Taxon
path: DataObject/DataAttribute1
- type: attributeEditor
properties:
# These are the CSS classes to apply
class:
pa-2: true
# This is the name of the Taxon
path: DataObject/DataAttribute2
- type: row
children:
- type: dataForm
properties:
# This is the name of the taxon that is
# the child data object
path: DataObject/ChildDataObject
children:
- type: row
children:
- type: attributeEditor
properties:
# These are the CSS classes to apply
class:
pa-2: true
# This is the name of the Taxon
path: DataObject/ChildDataObject/DataAttribute3