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:
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.
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:
CustGroup
as the CustGroup
typeCustGroup_DS
as the FormDataSource
typeCustGroup_Q
as the Query
typeCustGroup_QR
as the QueryRun
typeWe 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.
3.135.182.107