Although Dynamics AX is an international
product with support for multiple countries, languages, company sizes,
and industries within the same deployment, it is also a productive
development platform that ensures a uniform yet very configurable and
automatically arranged layout of application functionality. The unique
presentation technology is based on model element properties,
licensing, configuration and security settings, and personalization,
which together lay out the presentation controls on forms, reports,
menus, menu items, and corresponding Web elements for each individual
user. The technology is called IntelliMorph, and it works with both the
rich client and the Web client types in Dynamics AX.
A
primary driver of the IntelliMorph technology design is support for
international distribution, but with a different approach than other
enterprise resource planning (ERP) products; IntelliMorph needs to be
ready for multiple countries in multiple languages within the same
deployment, and it has to offer the same user experience, regardless of
the user interface language. These requirements necessitate the design
of a metadata-driven and property-driven user interface in which forms,
reports, menus, and menu items react to both global and local
configuration and security settings. A positive side-effect of this
design is that users can personalize the interface in multiple ways.
The personalization capability has been extended even further in
Dynamics AX 2009, in which individual users can choose from the
following options:
IntelliMorph
automatically arranges functionality based on licensing, configuration
and security, and personalization—without programmable changes. Figure 1 illustrates the filtering structure for the layout of elements such as forms, reports, menus, and Web pages.
The
layout includes the license code that opens the parent configuration
key, which holds either the security key references or the
configuration key children to the security keys. Security keys
determine access to the menu items that reference available
functionality for user groups and individual users. The final factor in
the interface experience is personalization, which allows the user to
modify the user interface by hiding, showing, and configuring the
presentation controls.
We describe the
elements and their interactions and dependencies in greater detail in
the following sections, and we also drill down on personalization
options.
Note
The
presentation and layout of the user interface are not limited to
support for IntelliMorph technology; they also provide a rich set of
design options for developing Windows forms with many different control
types, such as ActiveX and list view controls. You can also customize
Dynamics AX reports with the Visual Report Designer, which allows you
to visually design a report while using both the X++ syntax and the
properties window for arranging and formatting. |
Best Practices
Understanding
how IntelliMorph works can help you develop the run-time presentation
for application extensions. If you follow the best practice design
rules and patterns, you can optimize your use of the IntelliMorph
technology and ensure a uniform application run-time interface. The
best practice principles focus on using the default property settings
for the presentation controls that determine how to present elements
and functionality. They also cover the general use of labels, field
groups, extended data types, auto groups, security and configuration
keys, and menu items. The standard Dynamics AX application is developed
using all the best practice rules and patterns, which provide a uniform
way of interacting with the application and the underlying business
logic.
Principles for Forms
Designing
application forms can be a very time-consuming task if you always
design from scratch, especially if your application must run in a
multiple-language deployment. To avoid this time and effort, you should
follow the best practice of creating forms and reports by dragging as
often as possible and setting very few properties manually. If the
system’s default property values don’t suit your needs, you can
customize almost any property to fit your application.
When
you design the layout of a form for which a table or view is used as
the underlying data source, you find that the same field groups and
field structures in the original Tables and Views nodes are in the Application Object Tree (AOT). This allows you to drag these field groups and field structures from the form’s Data Sources node directly to the form’s Design node. You should configure the Data Sources to use the Dynamics AX AutoJoin
system to ensure that data is synchronized when two forms are linked.
When you work with the layout and property settings, you must keep the
Auto or Default settings. These settings optimize the use of the
auto-arrange technology and limit the need to move pixels to unify and
align the form presentation with the rest of the application.
When
designing forms, you should adhere to the recommendations in the
following list whenever possible to optimize the use of the
auto-arrange technology. Most patterns are property settings on the
form design.
Use default settings, especially for the attributes Left, Top, Width, Height, Frame, WindowResize, WindowType, and HideToolbar.
Use the DataGroup attribute when using tables or views as Data Sources.
When using the DataGroup attribute, change the AutoDataGroup property to Yes. This setting adjusts the overall behavior based on the data source behavior.
Use labels instead of hardcoded strings.
Add Help text (status bar Help) as labels instead of hardcoded strings.
Use the TitleDatasource property to provide a better and more visible data experience for the user.
Set the AutoDeclaration property to Yes if the control features must be accessible from X++ code.
Use the AutoJoin system where possible.
If
your customers require a unique user experience, you could completely
remodel the user interface—no design restrictions prevent you from
taking that step. One disadvantage of such an overhaul is that
training, flexibility, and upgrading become more complex.
Principles for Reports
IntelliMorph
is even more important for reports than for forms. The best practices
for reports primarily involve retaining the default settings for
properties. When you design a report, however, you often don’t know
much about the environment in which the report will execute. The
following examples illustrate the types of information you won’t have
at design time:
The size of the paper in the user’s printer
The length or content of the labels according to the user’s installation profile and language
The names of the fields disabled by security and configuration key settings
The length of the fields (extended data types) in the user’s installation
The sort order of the data sent to the report
Whether the user wants to print using the subtotals setting or just the totals setting
The default settings for font and font size
The number of records in the tables from which the report gets its data
Reports can be broadly classified into internal or external reports. Internal reports
are circulated and viewed only inside the organization. In such
reports, the report presentation and format aren’t critical. Some
examples of internal reports are Ledger Transaction List, Project
Profitability Statement, bank transactions, and so on. External reports
are circulated external to the organization, so their format and layout
are important. Such reports include Purchase Orders, Sales Invoices,
Vendor Check Payments, and so on. Such reports are usually printed on
preprinted stationery and require precision design. Both internal and
external reports can be created using the Auto design or Generated
design reporting features of Dynamics AX. You can use Auto design for
all internal reports and Generated design for external reports that
can’t be implemented with Auto designs because they require precise
design and layout capabilities such as the following:
Reports
that are forms with externally determined layouts and where the
information is expected to display in specific positions.
Reports
that are forms for which the design is likely to be adjusted to the
customer needs at deployment time. Invoices are one example. Most
controls should have their positions fixed (not set to Auto) to
simplify moving them by using the Visual Report Designer.
You should follow these design patterns whenever possible:
Use
default property settings, especially for orientation, width, label,
width of label, and other formatting information because fixed settings
cause the report controls to disregard the IntelliMorph auto-arrange
technology available from the property window.
Use the Auto design report type when possible.
Working with IntelliMorph
IntelliMorph
provides numerous options for personalizing Dynamics AX forms. These
options allow you to move controls, set properties on controls, and add
extra fields to forms. Forms are customized at application run time,
and settings are saved on a per-user basis. You can invoke the
personalization options from multiple places, depending on the type of
personalization desired. The personalization options use the same
framework whether a column is hidden via the Command entry on the menu
bar, moved within the form runtime by using the mouse, or renamed by
using the advanced personalization form.
The advanced personalization form, shown in Figure 2, provides the user with customization options.
By
using this form, the user can change the tab page order, move elements
around, remove fields, add additional fields from existing form Data
Sources, rename the field, prevent the field content from being edited,
change the default field length, and even choose among multiple
versions of the form presentation. The personalization settings can
also be shared. For example, a department that wants a common
presentation that differs from the standard company presentation but
doesn’t want to modify the global form layout could have all users
personalize their form settings in the same way.
To make user personalization work, you must define different levels of personalization by using the form design properties AllowUserSetup and AllowAdd. Four levels of personalization are presented in Table 1.
Table 1. Personalization Levels
| Personalization Level | Description | AllowUserSetup | AllowAdd |
|---|
| Limit user personalization of forms | User
can change only the size and position of the form, not the properties
of individual controls. Position and size of the form are saved (the
size is saved if SaveSize is set to Yes), so an entry for this form is in the SysLastValue table even though no personalization is allowed. | No | No |
| Enable customization of controls | User can change the behavior of individual controls but can’t move them or add new controls. Personal values can be defined for Enabled, Visible, Skip, Width, and Label. | Restricted | No |
| Enable customization of layout | User
can adjust properties on controls and move controls between containers,
move controls from within the Setup form by dragging or by using the
navigation buttons, and move grid columns within the grid by dragging
them directly onto the form. This feature lets the user create a tab
page that encompasses all the information normally entered for a given
record or grid, so most forms you create should support this level of
personalization. | Yes | Restricted |
| Enable customization of layout and content | User
can customize layout and add new fields from the Setup form. To support
this level of personalization, all code must be moved to the data
source fields. Added controls don’t have any code. The properties are
the default values for this type of control and data. Only data fields
can be added, not any unbound controls or controls bound to display
methods. | Yes | Yes |
The
personalization levels also depend on how the form’s X++ code is
written. For example, if you override the methods that take the
position of the control into account, the kernel can automatically
restrict the user setup level.
