You can save a query as a view. This way, you can explore your data without having to run the same queries over and over again. You can define how those results should be displayed in order to make them easier for people to read. You can also use views to input and edit data, and to perform actions.

There are different types of view, that display data in different ways.

You can display data using views on pages.

You can define views in workspaces.

Views have:

• Unknowns, which are names for the data values to retrieve
• Constraints, which determine the values to retrieve
• Columns, in which the retrieved values are displayed

A view is a saved query for data values that satisfy its constraints. The query retrieves combinations of data values. Each combination has a value for each of the unknowns, and is displayed as a row. The displayed values of each unknown form a column.

For example, a view to display a list of people might have:

• Unknowns Person, N, and L
• Constraints Person Has first name N and Person Has last name L 
• Columns in which the values of N and L are displayed, with a row for each person in the list.

Usually, the rows are displayed beneath each other, so that the columns form vertical lines in a table. Sometimes, the rows are displayed side-by-side; the values of an unknown are then still called a column even though they are not in a vertical line.

Some views just display rows of data. With other views, you can change rows and add new ones.

If a view allows user input, each row will be displayed with an edit button that the user can click to change the data in the row, and a delete button that the user can use to delete the row. The view will have an add button that the user can click to add a new row.

It is a good idea to give each view a description that explains what it does and how it is used. 

View descriptions are useful to the people that create and edit views, and to the people that use views when creating and editing pages. They are not normally seen by end users. 

View unknowns are names for data values to be retrieved. As well as being a name to identify the data values, an unknown also has a type, a sort priority, a sort direction, and an indication of whether it is editable

The type of an unknown determines how its data values are displayed, but does not affect what data values are retrieved. For example, an unknown might have integer type, but there might be a string value for it that fits the constraints. Perhaps a house number was entered as "three" instead of "3". The mis-typed value is still retrieved and displayed.

The type also determines how input data is treated, for example whether the character '3' is treated as the number three or as a text string.

In some views, the data is sorted for display. For example, a list of people might be displayed in alphabetical order of their last names, with people that have the same last name in alphabetical order of their first names. This would be achieved by giving the first name and last name unknowns sort priorities, with last name having a higher priority than first name. If first name was given a higher priority than last name, then the people would be displayed in alphabetical order of their first names.

The sort direction of an unknown can be set to reverse, so that its values are sorted from high to low instead of from low to high. For example, an Age unknown might be given reverse direction so that the older people are displayed first. 

Whether an unknown is editable determines whether its values can be set and changed when data is input, but does not affect how it is displayed.

The value of an unkown can be set for a page by a page assignment. This lets you use the same view to display different information on different pages. For example, you could have a view that can display people who are either business contacts or personal contacts. You could display the business contacts on one page and the personal contacts on another by assigning different values to a Contact Type unknown. 

A view's constraints determine what data is retrieved. Each constraint has a subject, a verb, and an object, for example Person Has First name N, and Person Has Last name L. Each row of retrieved data has a value for each of the unknowns, and the combination of values fits all of the constraints. These two constraints would produce a list of rows, each of which had a person's first name and last name.

A view with those constraints would produce a list of all the people in the system. Using more specific constraints can produce more targeted lists. For example, the last name constraint could be changed to Person Has last name "Smith". This would result in a list of all the people whose last name is Smith.

The subject of a constraint must be an unknown of item type or a specific item. (An unknown of item type has values that are items.)

The verb of a constraint must be an unknown of item type or a specific item.

The object of a constraint can be an unknown of any type or any specific value.

A constraint can be set as being unique valued. This determines whether multiple values are allowed when data is input, but does not affect display of the data.

A view column either displays the value of an unknown or contains buttons that the user can click to invoke actions.

A column can have a header that is displayed at the top, before the data or buttons.

An action is an operation on the data that is performed when a user clicks a button, or automatically when data is changed. Each action has a name, a trigger, an app, and a command.

The name is a string that identifies the action and is displayed on its button if it can be requested by users.

The trigger is the circumstance that causes the action to be performed. It is one of:

• Button - the action is performed when a user clicks its button
• Before Update - the action is performed when data is changed, before the change is made
• After Update - the action is performed when data is changed, after the change is made.

The app is the application that performs the action. These applications are system-defined, but include the remote application that sends a request to an external service.

The command is an application-dependant command that the application executes to perform the action. For the remote application, it is the URL of the remote service that will be requested to perform the action, and can be any URL. This allows the system to be extended by arbitrary custom remote services.