Transformer! 2.5 for Dynamics CRM Released

Hi Everyone,

Well I’ve yet again changed the name of my JavaScript conversion tool for Dynamics CRM, added a bunch of new features, and changed the licensing to better match my other products.

Visit the product page here.

 

Here’s an overview:

JavaScript Conversion

Since the initial release of the product, way back in November of 2010, I’ve taken a rather hands-off approach to the handling of certain code conversions. I know what needs to be done, but I always try to remember that it’s not my code and someone may not appreciate me mucking about with their JavaScript.  At least that is how I used to feel.

I now think it is most important to convert as much of the code as possible and produce as few conversion alerts as possible.

In some cases, I’ve modified the conversion alert process to only record the alert in the Conversion Report and not insert the alert into the JavaScript. Some things are nice to know, but you don’t want them to clutter-up your code.

Here are a few changes that I’ve made to the conversion of known issues:

 

Toolbar and Menu Manipulation

It was quite common in CRM 4.0 to hide and show toolbar buttons and menus programmatically. Since we’ve moved to the Ribbon in CRM 2011, this is no longer possible. In cases where such code is located, it will be commented-out to prevent runtime errors when the code is executed.

This may seem like a rather drastic step, but you would have had to perform the same action manually when refactoring your code so I decided to handle that process during the conversion. Here is an example:

document.all["_MBcrmFormSave"].action = "crmForm.SaveAndClose();";

 

// **Transformer!** Xrm.Page.getAttribute(

 

    /* CONVERSION ALERT */"_MBcrmFormSave").action = "crmForm.SaveAndClose();";

Any time you see "**Transformer!** in a comment, it is the result of an action that was taken during the conversion process. This text was inserted so that you may more easily locate these instances. In certain cases, the insertion of the comment could break existing logic so you will need to manually correct the issue yourself.

 

Partial Field Names

The fields on a CRM form are made up of two parts: The label and the data-entry control. These are named using the field name, with a "_c" added for the label and "_d" added for the control. I call these partial field names because the two parts make up the whole field.

In CRM 4.0, many developers used partial field names to perform JavaScript DOM manipulation such as showing and hiding the fields themselves, or the section or tab they resided in. Since this is not really necessary in CRM 2011, I decided to remove them, in a few special cases. This is a several-step process that works like this:

Any time partial fields are encountered using any of the following methods, the "_c" and "_d" are removed:

  • .Disabled
  • .disabled
  • .ReadOnly
  • .readOnly
  • .innerText
  • .innerHTML
  • .style.display
  • .style.visibility
  • Any method call where only the field is referenced, such as:

    DisableSectionFields(crmForm.all.acc_adusername_c);

The normal conversion happens, as it would for any other CRM 4.0 method. The side-effect to this process is duplicate code, for example: If we start with this:

crmForm.all.new_writeinproductname_c.style.display = 'inline';
crmForm.all.new_writeinproductname_d.style.display = 'inline';


we end up with: 

Xrm.Page.getControl("new_writeinproductname").setVisible(true);
Xrm.Page.getControl("new_writeinproductname").setVisible(true);

which is a waste of code (and time, for that matter). Transformer! will scan the fully-converted JavaScript file and remove duplicate lines, like the set above.

Here is an example of some CRM 4.0 code pre-conversion:

crmForm.all.new_writeinproductname_c.style.display = 'inline';
crmForm.all.new_writeinproductname_d.style.display = 'inline';
crmForm.all.priceperunit.ReadOnly = false;
crmForm.all.priceperunit.Disabled = false;
crmForm.all.new_newproductid_c.style.display = 'none';
crmForm.all.new_newproductid_d.style.display = 'none';
crmForm.all.new_productcode_c.style.display = 'none';
crmForm.all.new_productcode_d.style.display = 'none';
crmForm.all.productdescription.ReadOnly = false;
crmForm.all.productdescription.Disabled = false;

 

and this is what it looks like post-conversion:

Xrm.Page.getControl("new_writeinproductname").setVisible(true);
Xrm.Page.getControl("priceperunit").setDisabled(false);
Xrm.Page.getControl("new_newproductid").setVisible(false);
Xrm.Page.getControl("new_productcode").setVisible(false);
Xrm.Page.getControl("productdescription").setDisabled(false);

 

This can greatly reduce the amount of code controlling your user experience manipulation but it does have the unintended consequence of preventing an accurate comparison of the CRM 4.0 and CRM 2011 code when you are reviewing the conversion results using Transformer!’s Synchronize Scrolling feature.

 

Unsupported JavaScript

There are certain cases where it is necessary to customize the CRM user interface to perform a specific action or to inform the user of a specific condition or alert, or whatever. This was mainly accomplished by changing the .style property of a field.

Such actions were totally unsupported in CRM 4.0 and remain so in CRM 2011. Here is an example:

crmForm.all.new_status.style.textColor = "#000000";


The problem is that some organizations would like these features even though they know they run the risk of incompatibility with a future upgrade. That being the case, I have added an option called "Use unsupported customizations" which will allow you to choose to use a workable (right now) but unsupported solution: 

Xrm.Page.getControl("new_status")["_control"]["_element"].style.textColor = "#000000";

Again, this is unsupported code; it only applies to the .style property and it may not work in the next version of CRM.

Section References

New references to DOM elements representing the Section element are converted to the proper CRM 2011 equivalent:

 

crmForm.all.new_rep1commissionaccrual_c.parentElement.parentElement.parentElement.style.display = 'none';


becomes: 

Xrm.Page.getControl("new_rep1commissionaccrual").getParent().setVisible(false);

prependOrgName

prependOrgName is now being converted into: Xrm.Page.context.prependOrgName

 

ReadOnly

ReadOnly is now converted into setDisabled().

 

Stunnware

When Stunnware Filtered Lookup code is found, a note is made in the conversion report.

 

Outlook

Conversion of Outlook-related methods now more properly convert to

Xrm.Page.context.isOutlookOnline and Xrm.Page.context.isOutlookClient.

 

.text

Modified the manner in which .text was handled. In certain cases an improper conversion was made, mostly related to the handling of XML documents. This has been corrected.

 

Empty Event Handling

An issue was corrected where an error would occur when an empty script event was encountered. An exception would occur when an "empty" JavaScript file would be encountered.  Technically, it would not be empty, but would contain codes such as hard-returns, tabs, etc.  Visually it looked empty but there was enough contents to cause an issue. Not all events are stripped of trailing hard-return and tab characters.

 

ForceSubmit

In CRM 4.0 the method used to instruct CRM to submit a field to the database for updating, regardless of its ‘dirty’ state is called ForceSubmit, and is a boolean value.  CRM 2011 uses a method called setSubmitMode, which requires a string argument. This leads to problems when converting code like this:

crmForm.all.address2_line1.ForceSubmit =

 

  crmForm.all.rst_address2_sameasaddress1.DataValue;

 

The solution was to add a little JavaScript to the conversion:

Xrm.Page.getAttribute("address2_line1").setSubmitMode(

 

   Xrm.Page.getAttribute("rst_address2_sameasaddress1").getValue()

 

   ? "always" : "never");

This converts the boolean value of ForceSubmit to the string argument of setSubmitMode.

 

Hiding the Parent Row

Some developers were using code like this to hide the table row of the CRM form:

crmForm.all.isproductoverridden.parentElement.parentElement.style.display = 'none';

 

This now converts to the standard:

Xrm.Page.getControl("isproductoverridden").setVisible(false);

Changing Field Labels

This code:

crmForm.all.new_typenumber_c.innerText = NumFieldLabel;


now properly uses the supported setLabel method: 

Xrm.Page.getControl("new_typenumber").setLabel(NumFieldLabel);

Changing Tab Labels

This code:

crmForm.all.tab3Tab.firstChild.innerText = accountType + " Details";

 

now properly uses the supported setLabel method:

Xrm.Page.ui.tabs.get(3).setLabel(accountType + " Details");

 

Tab References

Instances where the name of a tab is being referenced by the textual name is now converted:

var tab2Hide = document.getElementById("tab" + tabIndex);


to: 

var tab2Hide = Xrm.Page.ui.tabs.get(tabIndex);

Precision

If the setting of the Precision property is found, the line will be commented-out since there is no CRM 2011 equivalent. Here is an example:

crmForm.all.new_contracttotal.Precision = 2;

 

onreadystatechange

The conversion alert for onreadystatechange was removed.

Unicode

An exception would occur when an invalid Unicode character was encountered. The parser was modified to handle a wider-range of characters to prevent this issue.

 

DataValue

Corrected conversion issues related to crmForm.all.field.DataValue when used with +=, -=, *= and /* .

 

Conversion Report

The conversion report has been modified slightly and the worksheets rearranged putting the most important information toward the front of the workbook while leaving the informational data toward the back.

One addition to the report is a list of iFrames found within your CRM forms. While this is not necessarily part of the JavaScript conversion process, I have found it very valuable during some of the conversions I have been involved with in the past few months.

 

User Interface Changes

The UI for Transformer! is slightly different than previous versions with the most important feature the addition of an options page.

Options

The following options are available:

Export folder allows you to select the folder where the conversion files will be placed.

ROI rate is the cost per hour should you feel the need to calculate how much time and Transformer! saved you.

Use Unsupported Customizations allows you to keep certain user interface element changes intact by using an unsupported method of coding.

Format JavaScript will reformat the JavaScript to make it more readable.

 

Pack And Go

Checking the Pack and Go checkbox on the ribbon will create a .Zip file containing all of the files generated by the conversion process. This is very useful should you need to upload or email the files to an associate or your consulting partner, or whatever.

 

Licensing Changes

I am changing the licensing to better match my other CRM-related products.

Note: Existing customers will not be affected by the these changes.

Single Organization License

  • $495 USD per CRM organization
  • Annual maintenance $90, 1st year included
  • One license covers use by unlimited developers
  • Supports a single CRM organization

Site License

  • $1,995 USD per development site
  • Annual maintenance $360, 1st year included
  • One license covers all developers within a single firm
  • Unlimited CRM organizations

Partner License

  • $9,995 USD per legal entity
  • Annual maintenance $1,800, 1st year included
  • One license covers multiple-office partner firms, all of their developers
  • Unlimited CRM organizations

Leave a Reply 0 comments

←Previous post Next post→