Mendix 7 is no longer supported unless you have Extended Support (for details, please contact Mendix Support). Mendix 7 documentation will remain available for customers with Extended Support until July, 2024.

Data view

Last modified: March 22, 2024

1 Introduction

The data view is a central component of Mendix applications. It is the starting point for showing the contents of exactly one object. For example, if you want to show the details of a single customer, you can 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 (for example, address and payment information) and data views and data grids for related objects (for example, order history or wish list).

2 Components

2.1 Data View Contents Area

The data view contents area is where all the layout and input widgets go. Often the contents area contains a table with two columns: the first column showing labels and the second column containing input widgets. 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 that 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.

3 Common Properties

Name

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.

Class

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

Styling is applied in the following order:

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

You can see which widgets in a page have styling applied via the class or style property by clicking the Show styles button.

Location and effect of the Show styles button

Style

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

For example:

background-color:lightblue; color:red;

will result in red text on a blue background.

You can see which widgets in a page have styling applied via the style or class property by clicking the Show styles button.

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

4 General Properties

4.1 Form Orientation

With this property, you can specify the position of the input widget labels inside the data view. If the orientation is horizontal, the labels will be placed next to the input widgets. If the orientation is vertical, the labels will be placed above the 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 a vertical orientation cannot be nested inside a data view with a horizontal orientation. In that case, the form groups will be rendered horizontally, regardless of the value of the orientation property.

Default value: Horizontal

4.2 Label Width (Weight)

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

Default value: 3

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 always invisible, regardless of the value of this property.

Default value: True

4.4 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. For more details, see Translatable Texts.

There are a 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

5 Editability Properties

5.1 Editable

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 is determined to be editable based on its own editable property.

Default value: True

5.2 Read-Only Style

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

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

Default value: Control

6 Data Source Properties

The data source determines which object will be shown in the data view. For general information about data sources, see Data Sources.

6.1 Type

The data view supports the following types of data source: context, microflow, and listen to widget. Whatever data source you select, the data view will always return one single object.

6.2 Entity, Microflow, Listen To Widget

See the corresponding data source for specific properties:

6.3 Use Schema

Curently this has no effect.

7 Visibility Properties

Visible

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.

Context

The widget can be made visible only if the object of the data view that contains the widget satisfies the specificied criteria.

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 they indicate that the billing address 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.

Based on Attribute Value

When selected, this shows the widget while a particular attribute has a certain value. Only boolean and enumeration attributes can be used for this purpose.

Based on Expression

Added in Mendix 7.1.

When selected, this shows the widget while a provided expression evaluates to true. The object of the containing data view is available inside an expression as a $currentObject variable.

Note that the expression is evaluated in the browser, and hence, we advise against using “secret” values (like access keys) in it. In particular, we disallow usages of constants. Also, client-side expressions currently do not support all the functions that are available in the microflows. Please refer to an autocomplete list to know what functions are supported in your version.

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.

8 Read More