DAXCONF - Patterns in building client forms & usability

Hi,

A number of new form patterns are introduced, documented and described in best practice documents: master data forms, header/line forms, transaction forms, parameters forms, …
Each type is described in UX (User eXperience) guidelines and development guideline documents telling you exactly how each formtype should look like, which controls suppose to be where on the form, which properties should be set, … in order to get a uniform Ax-look on all forms including the custom-ones.

Some facts about forms in Ax2012:- You can create a new form based on a form template so that you get a headstart on the basic layout of the form. A 'list page' style form has a filter group for example.
- The style of the form is defined by a new style property (=template described above), this property tells the form manager how to behave
- A form node in the AOT has a few new sub-nodes:
  - Permissions: helps you define which part of the form is accessible depending on security
  - DesignList : flat list of all form objects (see further down for details)
  - Parts: reference to 'parts' objects, defined in the new AOT node 'parts'
- A part actually is a form, but can be plugged into an 'fact box' on a list page form for example (in like a sort of widget)
- Tab pages are replaced by fast-tabs (=horizontal expandable/collapsable area's)
- The buttons on the right side of form are no more there: replaced by the action pane.
- A form has a view mode (to prevent unwanted data changes) and an edit mode
- Forms can have a detail view and a grid view (kind of like the 'advanced' button on the salesTable form in previous versions)
- A form can be published to the enterprise portal (just like that!)
- Quite some new properties are introduced:
  - Form controls have a property to define where they should exist: client and/or EP
  - A form has a interactionClass property, this class handles for example events for both the client and the EP (forms seem to be publishable to the enterprise portal)
  - several other properties (not only on forms) to realize what required lots of coding in previous versions

Besides the fast-tabs some other new controls are introduced:
- Drop dialog: a dialog sort of sticked to a form (so no separate form is created) activated from the action pane
- Enhanced preview: can be linked to a formcontrol via the previewPartRef property, enables you to extend the standard tooltip popups
- Fact box: typically on the right handside of detail and list pages, a collection of parts with additional data related to the active record (address, contact information, …)

Controls for managing information (country/region filtering)
- menu-items get an property representing the ISO code
- only the menu-items matching the current company's ISO code are shown
.Net controls can easily added to Ax + the events can be catched in X++.
Easier form customization:
- Besides a design, a new node 'designList' contains a flat list of all form contols (including new properties such as hierarchy parent).
- This node normally should not be used: changes in the design node are reflected here.
- Metadata is made much more granular (=reduced upgrade cost): like with tables and classes, controls on a form can be overridden without promoting the whole form object to the next layer (thanks to the designList)
- This obviously reduces upgrade costs on forms

Improved performance- Data method caching much easier (property 'cacheDataMethod' and code attribute on data method)
- onlyFetchActive property on datasources also used in inherited table structures

I know: it's quite a list and somewhat vague … but the demo's were pretty amazing. The draft version of the "What's new in Microsoft Dynamics Ax2012 for developers" document is about 80 pages … The complete what's new for Ax2009 was 51 pages. Go figure.