Posted on 24. May 2015

Turbo Forms: Get your JavaScript ready for CRM2015 Update 1

With the introduction of 'Turbo Forms' in CRM2015 Update 1 I thought I'd give you a heads up on what you'll need to address in your JavaScript to support this new form rendering engine. The Dynamics CRM Team Blog has a very good article on the changes but there have been some misunderstandings of the statement 'we have parallelized as many operations as possible'. In actual fact the script loading of custom web resource scripts has not really changed since CRM2013 - It remains the same as I describe in my CRM2013 Script Loading Deep Dive. The operations that are parallelized with turbo form rendering are the internal form load operations rather than custom ones. Custom JavaScript loading has always been parallelized since CRM2013.

Turbo Form Page Differences

Before Turbo Forms both global scripts and your custom web resources would have been loaded into a content IFRAME within the main window each time you navigate between records.

The biggest change with Turbo Forms is that the content IFRAME is kept in memory and re-used for performance reasons. This parent content IFRAME is even kept in memory between navigation between different entity types. Any custom JavaScript is then loaded into a child IFRAME (via the ClientApiWrapper.aspx page) so that when you navigate between records they are re-loaded.

SparkleXRM solutions already have a load order mechanism that ensure that your custom scripts are loaded in order that they are needed.

Impact on unsupported code

If your JavaScript is using only supported SDK calls then there will be no impact from this new loading mechanism. Sometimes it is necessary to use unsupported functions or referencing parameters of the Content IFRAME (such as the query string). Since your custom JavaScript is now running in the context of the ClientApiWrapper (rather than the content IFRAME) any reference to window methods such as window.openStdWin or window.location.href will fail. In order to access these objects you will need to reference parent.window.

The ribbon workbench 'how-to' article that shows starting a dialog from a ribbon button does infact use openStdWin to ensure consistency with the out of the box dialog experience. I have updated the code to use the parent window when required.

Footnotes

There are a couple of other notable aspects of Turbo Forms that I thought I'd point out:

IFRAMES that are collapsed by default are not sized correctly.

If you have an IFRAME or HTML Webresource inside a Tab that is collaposed by default you will find that they are not sized correctly when the tab is expanded. This will be fixed in an upcoming update but until then you will need to show the tab by default and collapse when the form is loaded.

entityType vs typename

Turbo Forms have dropped the typename attribute of Lookup values.

In the past, the following code would return the same:

Xrm.Page.getAttribute("parentcustomerid").getValue()[0].typename
Xrm.Page.getAttribute("parentcustomerid").getValue()[0].entityType

With Turbo Forms only the documented entityType is available. The typename attribute was left over from the CRM4 days and just had not been removed until now!

@ScottDurow

 

Comments

Hosk's Dynamic CRM  Blog Hosk's Dynamic CRM Blog
4:32 PM on Friday, June 12, 2015

Hosk’s Top CRM Articles of the week – 12th June

Article of the Week
The article of the week is my article is the excellent and I want as many people

pingback zsoltzombik.com
9:56 AM on Thursday, September 10, 2015

Pingback from zsoltzombik.com

Zsolt Zombik Dynamics CRM Blog’s Top CRM Articles of the week – 29th May | Zsolt Zombik's Dynamics CRM Blog

Comments are closed