Consistently using this or any other scaffold, especially in large teams/projects, can significantly lower the cost of maintenance as developers quickly learn to find the right location for new code or debugging breakpoint, even in code they have never seen before.
A few key concepts implemented by this scaffold:
- Using Namespace
Using namespace help avoiding collisions with other functions or variables in the global namespace. External solutions may contain code which is beyond your control and so it is important to protect your code from collisions that can be hard to detect and debug.
Using namespace also allow encapsulating private functions and variables while exposing public elements.
In this example, I am using ContactServices as my namespace. Consuming any public function from this class (e.g. form onLoad event handler) will use the namespace as prefix: ContactServices.HandleFormLoadEvent.
The ns alias is used to attach public functions to the namespace.
- ‘Constants’ management
Managing strings and magic numbers in a designated container lowers maintenance efforts as it eliminates the need to search for these values all over the code when a change is required.
The const keyword can be used, but I am not sure it is supported by all browsers.
- Generic event handlers
The scaffold generic event handlers match the entity form events. I like to think of these as managing functions which doesn’t perform actual work (like any good manager) but activates the relevant worker functions.
The ns prefix exposes the generic event handler as ‘public’ functions which can be wired to the form /attribute events.
In my sample here, I would use ContactServices.HandleControlChangeEvent to launch the generic onChange event handler. Note that some of these generic event handler require context, so either check this in the event definition form or extract with code if not supplied by caller.
Why should you use generic event handlers?
Attaching event handlers via form is simplified since the event handling function name never changes.
This is especially useful with attributes onChange event which is usually wired directly to event handling function.
The following generic event handler extract the initiating attribute name from the context and use it to direct the event to the actual handler. This way, all onChange event handlers can be managed in one known location.
The generic event handler also handles exceptions and frees the actual event handlers from this task. This way, no exception can escape your catch block.
- Public/Private elements
Private variables and functions are used inside the namespace scope and are not exposed to external consumers.
This allows exposing just the API you intend to and simplify matters for external consumers.
Functions and variables which are prefixed with ns are exposed outside the namespace, other are invisible.
To access a ‘public’ variable inside the namespace code, use this keyword.
The scaffold is not wired to any specific Microsoft Dynamics CRM version. These concepts can be applied down to 2011 version at least.
If you have any comments or improvements for this scaffold, I would like to hear about it. Share it here.