Ben Vollmer posted an article this morning about using the JavaScript Switch statement with a fairly good explanation of how it works and how it can be used as a replacement for the IF statement in certain situations.
That reminded me of a rather unusual Switch statement implementation that is found in the CRM SDK that I thought deserved a bit more exploration.
Before we get into that, let's take a quick look at the code Ben used in his article:
1: var prefix = "";
2: switch (crmForm.all.customertypecode.SelectedText)
3: {
4: case "Manufacturer":
5: prefix="MFG";
6: break;
7: case "Investor":
8: prefix="INV";
9: break;
10:
11: case "Press":
12: prefix="SCUM";
13: break;
14: default:
15: break;
16: }
17:
This code checks the value of the customertypecode field and sets the value of a variable prefix accordingly.
If you've ever browsed around the CRM SDK, you may have seen the following code demonstrating the CRM Form OnChange event:
1: // Attempt to auto-format basic US phone numbers. This method supports
2: // 7 and 10 digit numbers. Example: (410) 555-1212
3:
4: // Get the field that fired the event
5: var oField = event.srcElement;
6:
7: // If we have the field and all is well
8: if (typeof(oField) != "undefined" && oField != null)
9: {
10: // Remove any non-numeric characters
11: var sTmp = oField.DataValue.replace(/[^0-9]/g, "");
12:
13: // If the number is a length we expect and support, format the number
14: switch (sTmp.length)
15: {
16: case "4105551212".length:
17: oField.DataValue = "(" + sTmp.substr(0, 3) + ") " + sTmp.substr(3, 3) + "-" + sTmp.substr(6, 4);
18: break;
19:
20: case "5551212".length:
21: oField.DataValue = sTmp.substr(0, 3) + "-" + sTmp.substr(3, 4);
22: break;
23: }
24: }
This too shows you how to utilize the Switch statement, but as you can see, it's very strange looking and a bit hard to understand at first. I had to look at it several times to figure out what they are doing and realized that it is a very cool piece of code indeed.
What this code does:
This code segment checks the length of a string then formats the string if it meets one of two criteria for length. In reality, you could just have easily written the code as:
1: // If the number is a length we expect and support, format the number
2: switch (sTmp.length)
3: {
4: case 10:
5: oField.DataValue = "(" + sTmp.substr(0, 3) + ") " + sTmp.substr(3, 3) + "-" + sTmp.substr(6, 4);
6: break;
7:
8: case 7:
9: oField.DataValue = sTmp.substr(0, 3) + "-" + sTmp.substr(3, 4);
10: break;
11: }
Why this is cool code:
Instead of checking for a hard-coded length, the developer instead used a little JavaScript trick that allows you to work with properties of a literal value ( the stuff inside the quotes ). This actually makes the code self-documenting.
At this point you're probably wondering what in the heck I am talking about. Well, hang on for a bit longer and I'll explain everything.
If the CRM developer had written the OnChange code as shown in my second example, we would be left to wonder, "Just what they heck do the values 10 and 7 have to do with anything?" Unless, of course, they inserted comments that described those values.
As it stands, what the case statement actually does( in pseudo code ):
If the length of the variable sTmp is equal to the value of a phone number in the format: "4105551212" then I would like format the Form field as follows….
If the length of the variable sTmp is equal to the value of a phone number in the format: "5551212" then I would like format the Form field as follows….
While this may seem a bit odd and confusing, it's actually very practical. You can view the expected phone number variations while also seeing how the developer wished to handle the formatting for cases that matched their criteria. To add additional formatting choices, all you must do is copy the case block of code and change the length test and the resultant formatting.
Clear as mud?
Update Rollup 2 for Microsoft Dynamics CRM 3.0 is available. Download link.
The team at 37 Signals posted about a change in their development practices:
We recently decided to stop diving in too deep on tasks right away. Instead, we’re going for four hour chunks upfront. We start work on a task and then, after the first four hours, come up for air.
That is an absolutely terrific idea and one that you should consider implementing – I know I will.
So how does this apply to CRM?
As I tell my customers and other Microsoft Partners with whom I work, there are almost always two or three different ways to do everything within CRM. All of which are perfectly viable solutions. The trick is knowing which particular solution best fits the problem you are trying to solve.
The really tricky part is that sometimes what you know is the best solution, turns out to actually be the second-best solution. A fact that you didn't realize until you started work on it.
Or, if you start off with the phrase, "Well, it shouldn't be that hard," only to find out that while it didn't appear to be that hard, there were hidden factors that you simply could not have known until you actually started the development process.
It is the latter fact that gets most of us in trouble. Sometimes CRM just doesn't work the way you think it should, or the way you would like it to, and it can take quite a bit longer to develop a solution that expected.
So, the next time you jump into CRM solution development, set an alarm for four hours and when it goes off, take a break then reevaluate your progress when you return. Are we on the right track? If so, keep going, if not, find the next best course of action and restart the process.
Loading ...
