In the CRM 2013 release, significant improvements are made in the way forms are loaded in the browser. The new forms load more smoothly and perform better compared to previous releases. This blog post provides insight into the loading of forms for updated entities.
To make the user interaction with the updated entity forms smooth, the form loading process is split into multiple stages. These stages are:
The following diagram depicts how these stages are sequenced:
The first thing global.ashx JS library does is to retrieve layout and entity metadata from the browser cache. The layout is really an HTML template. The entity instance data retrieved during previous step provides data for the template.
This step involves doing the template binding of entity layout and entity data. Output of template binding is complete HTML. This HTML gets shown to the user. At this point, we can see all the data belonging to the entity instance requested by the user. This is called ViewReady or ReadReady state.
During previous stage, even though end user can see the data on the browser, the data can’t be modified for a small fraction of time. During this time, the controls representing the data are in a read-only state. To transition these controls into a state which allows them to be modified, a lot of things happen on the client side.
Post above steps, the controls are ready to be interacted with but not yet fully initialized. At this point of time, the controls are in a delayed initialized state. This means that when user actually clicks on the relevant area on the browser, the remaining initialization code gets to run. The motto here is to avoid paying penalty for executing code which might not be needed in the end. For example, assume there are 50 attributes (each attribute maps to a control) on the updated form, the user is probably going to interact with only a couple of those fields in most of the scenario. For that, it doesn’t make sense to pay upfront cost of fully initializing all these controls. If we were to fully initialize all the controls upfront, all the initialization adds up significantly. This will result in form being ready for user interaction quite late. On the other hand, if the control is initialized only when the user clicks an attribute, the single control initialization cost is too small to be noticed by the user.
Another aspect of control initialization is the phased approach taken to initialize controls belonging to various Tabs on the CRM forms. Typically CRM form attributes are split into multiple Tabs. Controls get delay initialized on the first Tab and then initialization proceeds to the next Tab.
Once controls in the first Tab are initialized, we call this state as Active Tab ready state. This means that user can interact with all the controls present in that Tab.
Once the forms are fully initialized, the control is passed over to web resources registered by the end user or shipped out-of-box.
For more information on forms, see the Customization Guide for Microsoft Dynamics CRM 2013 and Microsoft Dynamics CRM Online.