Most interfaces within Dynamics AX provide the user with the ability to search, amend, and perform actions based on data. For almost all interfaces we need to develop, there are standard patterns and templates provided to us to follow.
To help us, we are provided templates for most of these patterns. The templates available are as follows:
- ListPage: This provides a list of data (such as sales orders) and the ability to act on that data (post a sales order invoice). These are not used to edit or create data; this is what details forms are for.
- DetailsFormMaster and DetailsFormTransaction: Details forms have two types, master and transaction. Master detail forms are designed to amend and create master data, such as a customer. Transaction detail forms are used to amend data that normally has header and line views (for example, sales order details form). These forms are not normally used to create data; this is normally done in a custom form that allows the user to enter key information about the entity on a simple form.
- SimpleListDetails and SimpleList: These are usually used for setup forms, where the user opens the form directly from the menu. Simple list simply presents a grid of data that the user can edit directly. Simple list details shows a grid containing summary data with tabs containing the more detailed fields on the right-hand side.
Simple list is most suitable when the data is simply a list and the fields can fit without scrolling. Its details are more suitable where data benefits from being arranged in groups. The details version is also well suited to present data from a child data source.
- TableOfContents: These are used for parameter forms, where the table contains a record of parameters used for default or configuration options.
- DropDialog: This method shows a popup that allows the user to enter a small amount of information on a form, which appears to drop down from the button. This is useful to enter information about the current record, which requires a more assertive action, or to trigger a process. This is very similar in use to a dialog, but visually, it appears to be part of the calling form.
- Dialog: These are common for forms that start processes from the Periodic menu; although the SysOperation framework automatically creates dialogues for us, and therefore, reduces the number of times when this would be used.
The SysOperation framework is covered in Chapter 9, Advanced Features and Frameworks.
Most of the forms we create will use a data source whose fields are added to the form as data-bound controls.
Forms are normally structured as one or more data sources, with a design that holds the controls to interact with them. The data source can be a table or view, and in some cases (such as dialogs), they will not have a data source.
The structure of a typical form is shown in the following screenshot:
The form is based on the FormRun class. We can see this by opening (double-click) the classDeclaration for the CustGroup form:
public class FormRun extends ObjectRun
Therefore, you can think of the form as a definition file that FormRun instantiates with an order to build and execute the form.
Once the system has built the form design (using the SysSetupFormRun class), it will perform the initialization tasks and run the form. The key methods in this are Init and Run. These can be overridden on the form in order to perform additional initialization tasks.
One of the key tasks of the FormRun class's Init method is to construct the form's data sources. These aren't table references but FormDataSource objects constructed from the tables listed under the Data Sources node.
In the case of the CustGroup form, the system creates the following objects from the CustGroup data source for us:
CustGroupas theCustGrouptypeCustGroup_DSas theFormDataSourcetypeCustGroup_Qas theQuerytypeCustGroup_QRas theQueryRuntype
We aren't normally concerned with the Query and QueryRun objects, as we can access them through the FormDataSource object anyway. The CustGroup_DS data source is very useful, and will be explained in more detail in Chapter 4, Creating Business Logic and Hooking into Core AX, and Chapter 6, Extending the Solution.
The data sources are declared as global variables to the form, and provide a layer of functionality between the form and the table. This allows us to control the interaction between the bound form controls and the table.
For example, when a form control is modified, the control's modified method is called, which calls the data source field's modified method. This method in turn calls the table's modifiedField method with the ID of the field being changed.
The same goes for data source events. For instance, the write event on the form will call the data source's write event, which will call insert or update based on whether the record is new or not.
Based on this, we have a choice as to where we place our code. This decision is very important. The rule to follow here is to make changes at the lowest level possible: table, data source, and only at the form control if not possible at a lower level.
We can go further with this and write form interaction classes that allow user interface control logic to be shared across forms. For instance, controlling which buttons are available to a list page and the associated detail form.