Lists
Updated on Sep 23, 2022 8 minutes to readOverview
Each application component has its own distinct role. Most of the components work with data in one way or another, but the list is the most data-oriented component of the application. This is basically the data storage of the application. As you can probably guess by its name, List is a component to store and handle data lists. Different business processes require different lists of data like employees, products, clients, etc. These types of objects define the structure and properties of those lists.
Each list consists of list items. Depending on their rights, users can create, read, delete (CRUD operations) as well as export list items.
The List is a high-level application component intended to store and handle lists of data.
The Every8.Cloud Platform uses List components to create database tables and define their structure.
Attributes
Other than really simple lists, most other list items include additional data that further defines the item. For example, the list items of the list of clients will contain additional information such as address, phone numbers, account manager, and so on. This data set applies to all items of the list, and it is defined using the attributes of the list component.
Attribute is a middle level application component intended to define the additional information that further defines the list item.
The attributes are logically connected to the List component and referred to as subordinate.
The attributes can be of the following types:
- Primitive: date, number, string, time, etc.
- Referential: linked to another list or enumeration
- Applied: email, file, image, auto increment, etc.
Presentation Attribute
The totality of the user data is stored in lists. Lists are used as data sources for other lists’ attributes. Each list item has a unique ID stored in the table and used to identify it. This field is automatically populated and available in read-only mode. This is how the platform identifies list items.
Obviously, from the user perspective, this way of identifying list items doesn’t seem friendly. Additionally, not every list attribute is equally important. For example, selecting the city in the client’s profile, you would probably like to see the name of the city followed by the state/province like New York, NY or Toronto, ON; at the same time applying a payment to a sale invoice, it would be logical to see something like this: Sales invoice #00123 (2023-02-15).
As you can see, the presentation is the same in both cases but they are different.
Presentation is a predefined attribute that defines the default presentation of the list items across the application.
There are 2 ways to configure the Presentation attribute: using another attribute value (1) or using a template (2), which basically a formula.
Getting back to our examples, for the list of clients it would be logical to create a string attribute Name and define the presentation using this attribute.
In case of list of cities, the Presentation attribute would be a template: {{object.name}}, {{object.state}}, where name would be a string attribute, while state would be a reference to another list item.
Using template, the Presentation may also include the values of attribute’s attributes. Defining the Presentation of the city list item as a template {{object.name}}, {{object.state}}, {{object.state.country}} the default presentation would be New York, NY, USA.
Tabular Inputs
Tabular input is a second-level metadata object intended to store additional data set subordinated to a specific list item.
List items can also store some data of identical structure but of different quantity. For example, a sales invoice may have one line, while another one may have a thousand lines. But the structure of those lines will be identical: ‘Billing item’, ‘Price’, ‘Quantity’, ‘Amount’. Tabular inputs are used to describe this kind of data relation.
Each list may have an unlimited number of tabular inputs. It could seem that a tabular input is just another list linked through an attribute referenced to the parent object. Even though it is almost true from the data structure perspective, from the business logic perspective, there is a big difference between those two approaches.
Tabular inputs are an integral part of the data object, that means that they are read and saved with the object. As you know, a data object is much more than just a record in a table. When a data object is saved, the platform fires triggers, event handlers, adds records in the audit log. A record in a tabular cannot be changed without saving the whole object.
Let’s see when a linked list should be used over a tabular input:
- If there may be a need to refer to the records of the tabular input as data objects. Ex: List of family member in an employee profile. If there may be a need to treat the family members as separate data objects, a linked list should be used.
- Since all tabular input data is read and saved with the data object, the possible size of tabular inputs should be considered. If a tabular input may contain thousands of records, you should probably opt for a linked list vs tabular input.
Forms
The purpose of any given list will affect how the list items should be presented (which view).
When you are looking for a specific client, it would be easier to see all clients presented as a list, while modifying a client’s profile would require a completely different layout.
There are 2 types of forms that can be used for a list object:
Object form – item form, intended to be used to create or update the list item. List form – default presentation of a list as a table.There are 2 types of forms, but not every list will have 2 forms. Some simple lists may have only 2 forms (list and object), while other ones may have multiple forms of each type.
Now, you might be wondering when you would even need to create several forms of the same type.
There are 2 reasons you would want to do this:
- Different forms for different scenarios. Ex.: full client’s list form with a lot of columns for CRM purposes, and a simplified list form for accounting module with the Current balance column.
- Different forms for different security roles based on users’ access rights.
Each form can be configured as a default form for specific user security roles.
A sales manager can see one data set, while an accountant a different one in different layout.