Skip to main content
A newer version of this page is available. .

View Items Layout Generation

  • 3 minutes to read

The eXpressApp Framework automatically generates all Dashboard Views and Detail Views according to the Application Model information. There are certain rules used to generate a default layout that minimize required customizations. These rules are described in this topic.

Dashboard Views and Detail Views are generated using the information which is stored in the Application Model‘s Views | DashboardView and DetailView nodes. These nodes have two child nodes: Items and Layout. The former is used for populating the CompositeView.Items collection. The latter is used by the View’s Layout Manager to arrange the Layout Items created for each item from the Items collection. The following image demonstrates both the Items and Layout nodes.

Layout_ModelEditor

Note

Mobile applications do not support the DashboardView and Tabbed Group.

The rules by which the Layout node is generated for Detail Views are the following.

  • A Layout Item is generated for each View Item form in the Items node. Note, that the Items node only contains Property Editors by default (see Business Model in the Application Model). In addition, Items are not generated for the properties that use the VisibleInDetailViewAttribute attribute with the parameter value set to false.
  • If there is a single Property Editor that represents a property of the XPCollection type, an individual Layout Group is created.
  • If there are several Property Editors that represent a property of the XPCollection type, an individual Tabbed Group is created.
  • If there are Property Editors that represent simple properties, such as value type or enumeration properties, an individual Layout Group (“SimpleEditors” group) is created. If there are more than four of these Property Editors, two Layout Groups are created within the “Simple Editors” group, and the Property Editors are divided between these groups. Created Layout Groups are aligned horizontally, and Editors are placed vertically within them.
  • For all remaining Property Editors, a “Sizeable Editors” Layout Group is created.
  • For Property Editors that represent inherited properties, individual groups are created within the common Layout Groups.
  • Within a group, Property Editors are sorted first by IModelCommonMemberViewItem.RowCount, then by IModelNode.Index, then by business class’ property declaration order. The Index property can be set in code using the IndexAttribute.

Consider the following example. In the following picture, the image on the left illustrates an auto-generated layout for a sample Contact business class’ Detail View. The image on the right illustrates the auto-generated layout’s structure.

LayoutSideBySide

  • The Contact class inherits from the Person class, which has some public properties. So, two nested Layout Groups are created in the Simple Editors Layout Group - Contact and Person.
  • The Contact class has only four public properties, so their property editors are put straight into the Contact Layout Group.
  • Since the Person business class exposes more than four public properties, two nested Layout Groups are created - the Person_col1 and Person_col2. The Property Editors that represent the public properties of the Person class are divided between these two Layout Groups.
  • The string type Notes public property belongs to the Contact class. However, it has the Size(-1) attribute applied, so it is assumed that its Property Editor will have a variable height. That is why the Notes Property Editor is put into the Sizeable Editors Layout Group.
  • Finally, Task, Change History and Phone Numbers are XPCollection type properties. So the Tabs Tabbed Group is created, and each Property Editor is put into an individual Layout Group.
See Also