Developer 101 - Modules

In the “Define and create a Page Template” lab, we used the built-in Rich Text Module to illustrate how modules can be added to a page. Now we can discuss modules in more detail so that we can create a custom module to implement some specific functionality.

Modules are the individual functional components that populate a page layout. Since the module framework is basic and allows a high-degree of customization, the complexity of a module can vary from displaying a simple piece of text to a more complex form that collects and stores data somewhere.

By default, only two modules come built-in with Agility (Rich Text Area and Form Builder). It is expected that a developer will build a library of modules for editors to use that are designed specifically based on their requirements.

From a developer’s point-of-view, a module is either a Partial View or Controller ActionResult combination that encapsulates a specific section of the web page. This module then will include the mark-up to render the module, as well as any relevant business logic and JavaScript to make it interactive.

From the content editor’s point-of-view, a module is an input form that appears when they select a module when adding it to a module zone on a page. This input form is the list of customizable properties of the module, such as titles, text labels, links, etc.

You can see the list of modules that already make up our Sample Site by navigating to Settings > Module Definitions.


Some of these modules are of the more complex variety, and depend on data such as query strings and dynamic routing via Dynamic Pages. There are also more simple modules (such as the Jumbotron) that is simply a Heading, some Rich Text and a link.

You can click on any of the module definitions to see its properties dialog, summarized as follows:

General Settings

  • Name - this is simply the reference name displayed to content editors when they are searching for a module to add to a content zone, or reviewing the modules that have already been added.

  • Reference Name - similar to the reference name of a page Content Zone in a page template, this is a name for the website code to use when referring to the module.

  • Description – this is a mandatory field that is used to help content editors see what functionality they can expect from a module when adding it to a content zone.

The remaining checkboxes are important, but not relevant for this introduction to Agility.

Form Builder

This tab is where you define the individual fields that make up the input form of a module – these are defined in the Architecture stage of website development and their usage can vary.

Standard Field

Fields can have various types, including Text, HTML, Number, Date, URL, Image, Image Gallery, File, and Linked Content. This wide variety in itself illustrates how diverse the usage of properties can be and will be discussed in the later labs.

Custom Field

There are some cases where you may want to create your own custom field. Custom Fields allow developers to define an HTML template, and JavaScript model to render and save their own field values. An example where this could be beneficial would be when a developer needs to pull in some data from a third-party source to populate dropdown values.


Tabs can also be used to group properties together – all properties underneath a tab will appear grouped when the module’s input form is rendered. For example, a module that represents a form on a website might group all of the field labels in one tab and all of the validation messages in another.

Custom Section

Custom sections are used to insert rich text into a module input form – normally this is for instructional purposes.

Form Customization

Typically, you will use the System Generated Input Form as this helps to maintain consistency for the content editors and makes maintenance of modules much easier. Options for Customized Input Form and Internal iFrame are deprecated and only supported for legacy purposes. 

Custom Script allows you to specify certain JavaScript to be executed on input form events.

Output Template

The Output Template defines what code will be executed when this module is being rendered in a page. For MVC projects, you can either specify either in Inline Code, a Controller Action, or a Partial View.

Inline Code is a cloud alternative managing code files without requiring a website deployment or integration with source control, but is not relevant for this introduction.

The Controller and Action option will simply execute the specified Action, passing through all of the module properties in a strongly typed object. The Partial View option will use the built-in Agility controller to execute the specified partial view, again making the module properties available in a strongly typed object.

Partial View Code:

Controller Action Result Code:

Page Usage

Page Usage contains a list of pages that have this particular module implemented on them. This is for information only.

1 out of 1 found this helpful



Please sign in to leave a comment.