Modules and views

In a Kendo UI Designer web app, the module is the basic unit of application functionality. Each module contains one or more views that provide the functionality, typically for a common set of features. Therefore, a view provides the UI for a single application function or feature within a module.

As described in Creating and designing an app, when you first create a web app in the Designer, it creates one built-in Application module. You can then create as many additional user-created modules as you require to organize the features of your app.

At design time, you can edit properties of the login view on a view design page. However, the landing-page view has editable properties only for changing the default names of general event handler functions, which can also be changed for all views (see General view events). Otherwise, the run-time behavior of the landing-page view largely depends on the user-created modules that you create for an app (see App layout and components).

User-created modules — Created with no default views, you can create as many user-created view instances as you need from a set of supported view templates. You can create two types of user-created views: predefined views and user-defined views. A predefined view has a responsive layout and content that is defined entirely by its template. Currently, the Kendo UI Builder supports three Data-Grid* templates for predefined views that all contain a single grid or a combination of a single grid and form whose content depends on the data bound to the view. A user-defined view supports a responsive layout and content that you define entirely from components you drag-and-drop on a view design page. Currently, the Kendo UI Builder supports a single Blank template for defining user-defined views.

To display and update data in a user-created view instance, you must specify at least one data resource instance from any available data provider in order to bind data to the view and its components. The predefined Data-Grid* view templates allow you to specify a single data source per view instance and both the display and update of data in the view can be implemented with little or no additional programming.

The user-defined Blank view template allows you to specify multiple data source instances per view instance. Each data-bound content component can be bound, either directly or indirectly, to a single data source from the those you have specified for the view. However, for the Blank view, the display and update of data in the view requires additional programming, depending on the content components it contains and their data binding.

Data-Grid — This view is a predefined read-only or editable grid that displays rows of records on the app views page from a single view data source instance you specify on the view design page. If it is editable, this view provides a design-time choice of three edit modes for editing the grid either one row one at a time or one page of rows at a time.

Data-Grid-Form — This view includes a predefined read-only grid, similar to the Data-Grid in read-only mode, and also includes a form with a design-time choice of two edit modes: a read-only or read-only-to-edit form that displays with the grid in a single split screen on the app views page. This form allows you to display and update fields from a single view data source instance you specify according to the editor type defined for each field in the data source. This includes built-in support for look-up editor types that enable foreign key access to field values in a parent data source. Note that for foreign key support, both the view data source and the parent data source used for look up must represent top-level tables in their respective Data Object resource (or resources), and cannot be part of a parent-child data-relation defined for any single Data Object resource.

Data-Grid-Separate-Form — This view includes a read-only grid, similar to the Data-Grid in read-only mode, and also includes a form with a design-time choice of three edit modes: a read-only, directly editable, or read-only-to-edit form that overlays the grid in a separate screen on the app views page. This form allows you to display and update fields from a single view data source instance you specify according to the editor type defined for each field in the data source. This includes built-in support for look-up editor types that enable foreign key access to field values in a parent data source. Note that for foreign key support, both the view data source and the parent data source used for look-up must represent top-level tables in their respective Data Object resource (or resources), and cannot be part of a parent-child data-relation defined for any single Data Object resource.

Stacked-Data-Grids — This is a parent-child view that displays two grids on a page, where the first grid displays records from a parent data source and the second grid displays records from a related child data source directly below the parent grid. The parent grid is read-only. When the user selects a parent row, the related records from the child data source are displayed in the rows of the child grid, which can be either read-only or editable, similar to the Data-Grid view. This view allows the user to display and edit child rows for only one parent row at a time. Note that the parent and child data sources accessed by this view must be part of a parent-child data-relation defined for a single Data Object resource.

Hierarchical-Data-Grid — This is a parent-child view that displays a single hierarchical grid structure on a page containing both parent and child rows. Initially, the grid displays only rows from a parent data source, which are read-only. When the user clicks an expander on any parent row, a child grid opens indented under the parent row and displays records from the related child data source. The user can individually expand multiple parent rows, which allows the user to display multiple child grids under their respective parent rows at one time. The child grids can all be either read-only or editable, similar to the Data-Grid view. For editable child grids, the user edits and saves row changes for only one child grid at a time. Note that the parent and child data sources accessed by this view must be part of a parent-child data-relation defined for a single Data Object resource.

Blank — This is a user-defined view that allows you to define both its layout and content by dragging and dropping a variety of components, including layout (rows and columns), data management (e.g., Grid), editor (e.g., Text Box), scheduling (e.g., Calendar), charting (e.g., Bar Charts), navigation (e.g., Toolbar), and custom HTML components. The layout is based on a Bootstrap fluid grid system that you can define initially with row and column components. The content consists of individual UI components, many of which you can bind to data. You can add these components either to existing rows and columns or directly to any existing row, which implicitly creates a column for that component if necessary.

The Blank view thus allows you to build a custom view that can be a variation on the predefined Data-Grid* views or something completely different, such as a stand-alone form with data navigation and without any associated grid. Unlike the Data-Grid* views, the Blank view allows you to bind multiple data sources from one or more data providers. You can then bind each content component in the view to any one of these data sources. To complete this data binding for a Blank view, you must code event functions as required for the content behavior you want in a JavaScript file that the Kendo UI Builder generates for the view.

The editor components for a Blank view include Combo Box, Drop Down List, and Plain Text components that correspond to the editor types that support foreign key look-ups for Data-Grid views with forms. However, unlike in Data-Grid views with forms, this foreign key look-up support is not built-in for the corresponding editors of the Blank view. You must, instead, add custom code to implement a foreign key look-up for a Blank view. For an example, see Adding and editing a Blank view.

The design-time properties available to customize Data-Grid* view instances are all very similar from one view template to the next, with additional properties added for the more complex views with forms and parent-child views. In addition, for those views with forms or parent-child grids, only one design-time property setting is required to change from one supported edit mode to another.

The design-time properties and code to customize a Blank view instance depend entirely on the view content components and data sources that you use to define and bind data to the view. Some properties are available in many or all of the components, but many are unique to a subset of components.

Note that Kendo UI Builder supports two kinds of templates: built-in templates and custom templates. The built-in templates are installed and available for any project that you create in the Designer. Customization of built-in templates is limited to your settings of installed properties in the Designer, event function code that you write for existing events, and custom HTML sections that you code as prescribed for each built-in template.

Custom templates include both custom view templates, which are based on the five predefined view templates described here, and custom component templates, which are based on a supported selection of built-in components, and which you can use as part of the built-in Blank view template. You can customize the source code for custom templates in any way that works for your organization and use them in the Designer much like the built-in templates, but based on your modified source code. Note that unlike built-in templates whose features are available in every project, these custom templates are project based. This means that any source code customizations you make apply only to the web app project where they reside.

You can customize views that you create from both built-in and custom templates with additional code and settings at a number of extension points in your Kendo UI Builder installation and web app folders, including AngularJS files for coding view event functions and custom HTML files for coding custom HTML sections. For more information, see Extension Points and Source Code Customization.

The following topics provide a more detailed overview of both the built-in login view and the user-created views and their templates. The description of each view builds to some extent on the next to provide a comparative overview of their capabilities.