Data view

Last update: Edit

The data view is a central component in Mendix applications. It is the starting point for showing the contents of exactly one object. If, for example, you want to show details of a single customer you would use a data view to do this. The data view typically contains input widgets like text boxes with labels. In more complex screens, a data view can contain tab controls per topic (address, payment information) and data views and data grids for related objects (order history, wish list).


Data view contents area

The data view contents area is the place where all the layout and input widgets go. Often the contents area contains a table with two columns with labels on the left and input widgets on the right. Other layouts are possible as you can see in the examples above.

The footer of the data view is the section at the bottom of the data view which often contains buttons to confirm or cancel the page. However, arbitrary widgets are allowed. The footer will stick to the bottom if the data view is the only top-level widget.

Data view control bar

The control bar of the data view is the bar with buttons at the bottom of the component. By default, it contains a Save and a Cancel button but the bar can be customized. A read-only data view would typically provide only a Close button. You can add buttons with custom behavior through the use of a microflow button.

See Data view control bar for a description of the buttons and their properties.

Common properties


The internal name of the widget. You can use this to give sensible names to widgets. The name property also appears in the generated HTML: the widget DOM element automatically includes the class ‘mx-name-{NAME}’, which can be useful for Selenium testing.


The class property allows you to specify a cascading style sheet (CSS) class for the widget. This class will be applied to the widget in the browser and the widget will get the corresponding styling. You can use more than one class, separated by a space. The classes should be classes from the theme that is used in the project. Using the class property overrules the default styling of the widget.

Note that the styling is applied in the following order:

1. Default styling defined by the theme the project uses.
2. The 'Class' property of the widget.
3. The 'Style' property of the widget.


The style property allows you to specify additional CSS styling. If a class is also specified, this styling is applied after the class.

background-color:blue; This will result in a blue background

Tab index

The tab index influences the order in which the end user navigates through the page using the tab key. By default tab indices are zero and the tab order is determined automatically by the client system. A value of minus one (-1) means that the widget will be skipped when tabbing through the page.

Default value: 0

General properties

Form orientation

With this property you can specify the position of labels of input widgets inside the data view. If the orientation is horizontal labels will be placed next to input widgets. If the orientation is vertical labels will be placed above input widgets.

Note that form groups are responsive and the labels may be placed above input widgets even if the orientation is set to horizontal, depending on the viewport size. Also note that a data view with orientation vertical can not be nested inside a data view with orientation horizontal. In that case form groups will be rendered horizontally regardless of the value of the orientation property.

Default value: Horizontal

Label width (weight)

If the form orientation is set to horizontal this property can be used to specify the width of labels of input widgets inside the data view. The width is specified using column weights from the Bootstrap grid system (see Layout Grid).

Default value: 3

Close on Save/Cancel

Using this property you can specify whether you want the current page to be closed when the Save or Cancel button is clicked. After closing the current page, the client will return to the previous screen. This property only has effect for data views that are shown in the content pane (as opposed to in a popup).

For example, you have a data grid with customers and the edit button of the grid directs you to a data view in content showing the details of one customer. After clicking Save or Cancel you want the application to return to the page of the grid. In this case you want the property ‘Close on Save/Cancel’ to be true.

Default value: True

With this property you can specify whether you want the footer of the data view to be visible. The footer of nested data views is invisible by default regardless of the value of this property.

Default value: True

Show control bar

With this property you can specify whether you want the control bar of the data view to be visible. The control bar of nested data views is invisible by default regardless of the value of this property.

Default value: True

Empty entity message

If this message is specified, a data view that receives no source data will show this message instead of its content. Otherwise, the data view will show its static content and disabled input widgets. This property is a translatable text. See Translatable Texts.

There are number of ways a data view can end up without source data. For instance, a data view with a ‘Listen to widget’ data source will remain empty until an object is selected in the target grid. In this scenario, ‘Empty entity message’ can be used to guide the user to select an item from the grid.

Default value: empty

Editability properties


The editable property indicates whether the data view as a whole is editable or not. If the data view is not editable, no widget inside the data view will be editable. On the other hand, if the data view is editable, each widget can be editable or not based on its own editable property.

Default value: True

Read-only style

This property determines how input widgets are rendered if read-only.

Value Description
Control Widget is displayed but disabled so the value cannot be modified.
Text Widget is replaced by a textual representation of the value.

Default value: Control

Data source properties

The data source determines which objects will be shown in the data view. For general information about data sources, see the data sources documentation page.


The data view supports the following types of data sources: entity (path), microflow and listen to widget.

Other properties

See the corresponding data source for specific properties:

Use schema

This defines whether only the required attributes and associations for the object(s) are retrieved. This can sometimes improve your performance but it can also reduce performance because the objects can not be cached entirely. If you have custom widgets in your page and they need access to other attributes or associations, or if your next page contains other attributes or associations of the same object(s) you should not enable this. This is why the default value is false.

Visibility properties


By default, whether or not an element is displayed in the browser is determined by how the page is designed and the user’s roles within the application. However, the page can be configured to hide the element unless a certain condition is met.

Attribute Condition


When checked, this setting hides the widget unless a particular attribute has a certain value. Only boolean and enumeration attributes can be assigned to this purpose.

A practical example would be a web shop in which the user must submit both billing and delivery information. In this case you might not wish to bother the user with a second set of address input fields unless he or she indicates that the billing and delivery address are not the same. You can accomplish this by making the delivery address fields conditionally visible based on the boolean attribute SameBillingAndDeliveryAddress.

Module roles

The widget can be made visible to a subset of the user roles available in your application. When activated, this setting will render the widget invisible to all users that are not linked to one of the selected user roles. Please note that this does not override project security. Any restrictions due to microflow, form, or entity access will remain in effect.