So this is the conclusion to my JavaScript Upgrade Strategies series. So now that I have told you how to do all of these things, how about asking why? Here is why: Reduced code-base Reduced maintenance Faster user experience Real Data Points Here are the results after applying the conversion strategies we discussed to […]
Continue readingNothing beats real testing to shake out the bugs on a newly migrated system. These should include: Real users Real data Actual processes This should be of no surprise to anyone, but the idea that having real users test the system is far better than just have the development staff perform tests. And this type […]
Continue readingAs you are migrating and testing your code, it may be a good idea to disable any plugins that fire when you are creating and updating a record. This allows you the freedom to test your JavaScript without having to worry about other system components causing issues during the testing process. We do this because […]
Continue readingMinification is the process of reducing the amount of space a JavaScript file occupies by removing things like formatting and comments and overall rewriting the code to take up less space. This generally gives you a slight gain in performance because smaller files are faster to download from the web site. The biggest issue you […]
Continue readingSpeaking of feature creep, web resources are one of the few system-level data items that can sort of build-up over time, if not properly maintained. Again, this happens because of a change in business direction, a rewrite of functionality, etc. Most of the time, these unused web resources cause no problems at all, other than […]
Continue readingI really cannot emphasize this enough, but this is your chance to fix all of your code and architecture issues. You are taking the time to, in most cases, upgrade your hardware platforms, move the databases around, etc., so why would you not spend time fixing code that has existed for years. The chances are […]
Continue readingI run into this occasionally when converting Dynamics CRM 4.0 JavaScript into the 2011 object model. Consider this piece of code: if ((crmForm.all.new_field1.DataValue >= 3) && (crmForm.all.new_field1.DataValue <= 10)) { sitetotal = 2; } else if (crmForm.all.new_field1.DataValue > 10) { sitetotal = 3; } else if (crmForm.all.new_field1.DataValue = 0) { sitetotal = 0; } Can […]
Continue readingAs I have stated previously, if you are not using Visual Studio to edit your Dynamics CRM JavaScript, you are doing yourself a huge disservice. Consider this code: Can you spot the problem? Visual Studio and Resharper did. Notice the blue line under Industrytotal? It is there because Industrytotal has not been defined […]
Continue readingAs with many things in Dynamics CRM Development, there are more than one way to do the same task. Take the addition of an OnChange event handler, for instance. A Little Background Here is how we would normally configure an OnChange Event that automatically formats a phone number field: This links to […]
Continue readingStarting with Dynamics CRM 2011, we have the ability to hide form elements (fields, sections, tabs) by using either JavaScript or by setting the Visible by Default property using the properties dialog for each individual form element. If you are upgrading your JavaScript from Dynamics CRM 4.0, you probably have code in your OnLoad event […]
Continue readingAgain, since we are in refactor mode, now is the time to fix all of your previous decisions. Some, or in some cases, many of those decisions involved using unsupported JavaScript. In the days of Dynamics CRM 4.0, we had to do a lot of unsupported code to provide the responsive user experience we needed […]
Continue readingWhen developing in Dynamics CRM, sooner or later you will find a requirement to perform some type of database operation. In Dynamics CRM 4.0 we had to the choice of creating raw SOAP requests or by using a library from Ascenitum (later Avanade), to perform these operations. When upgrading to Dynamics CRM 2011, you have […]
Continue readingWhen your Dynamics CRM 4.0 JavaScript is converted to the Dynamics CRM 2011 object model, all of the events are consolidated into a single web resource that may look something like this: As you can see from each of the OnChange events above, you can end up with a situation where all the […]
Continue readingContinuing on our refactor process, we enter the code consolidation phase. This includes the following processes: Remove duplicate functions One of the features of Transformer! is to identify duplicate functions when performing the conversion process but you can always just hunt these down manually, if necessary. There are actually two types of duplicates that […]
Continue readingOne of my absolute joys when upgrading a Dynamics CRM organization from 4.0 to 2011 is the chance you get to actually remove JavaScript from your system. Remember: Code that you do not have, is code you do not have to maintain. Part of the consolidation process is to remove as much JavaScript as you […]
Continue reading