Dharmesh Shah asks:
I’m exploring the use of third-party controls (like Infragistics, ComponentArt, etc.) within my custom modules. My first round of experimentation with Infragistics seems to indicate a problem because of some of the Javascript and other stuff the control tries to insert. Do you have any tips or experience in using these types of controls inside a DNN module?
Nik’s response:
This is an issue that is going to plague DNN developers for some time to come. To understand why, let’s examine how components use Javascript.
Generally speaking, a third-party component will inject JS into your page in one of two ways: (1) by having a <script src=”…”> tag that links to a .js file, or (2) by injecting the script in-line using a <script> tag without the “src” attribute. The former is more efficient because it can benefit from browser caching. It is used for generic code and not for instance-specific initialization etc. The latter is necessary because it allows server-side code to create script on-the-fly. For example, in order to render the portal menu, the data for the menus is rendered on-the-fly.
Most components are written for ASP.Net applications. Your average ASP.Net application makes use of usercontrols for “shared code” to avoid repeatedly coding things such as headers, footers, feedback forms etc. Embedding a third-party component into these usercontrols is not a problem because it is rare that the same usercontrol is used multiple times on a page. In the case of DNN, usercontrols manifest themselves as “modules” and as any DNN user knows, a module may appear any number of times on a page. This is where the problem begins.
Forward-thinking component developers have envisioned this scenario and taken measures necessary to ensure the uniqueness of dynamically injected variables and objects in code. If a component developer has not done this, it’s game over when you have multiple instances of the component on the same page since the initialization code will reference only the last instance (if it even works). For example, let’s say we have an image with an ID of “MyImage” and there is a variable tracking the position of this image. The (unoptimized) code injected might look something like this:
var imgX = document.getElementById(“MyImage”).left;
var imgY = document.getElementById(“MyImage”).top;
If this code appears in a DNN module that is instantiated four times on a page, imgX and imgY will be set to the last occurrence of the code. Any further U.I. manipulation by JS will throw errors or produce generally erratic behavior.
This is the first thing to look for in a third-party component that uses client-side JS. Does it have the ability to be instantiated multiple times on the same page. The test scenario for this is easy. Download the trial version and modify one of the samples so two instances of the component are on the same page (do give them different ID’s). Does it work? If it seems to be working, double-check the page source. Look for Javascript variables and ensure that variables have a unique prefix or suffix. In most cases this will be driven by the ClientID property of the usercontrol as this is the Microsoft-recommended property to use for client-side identiciation of server-side controls.
I wish I could say that there was an easy workaround if the component does not readily allow multi-instance capability. There just isn’t. Your best bet is to contact the developer and make them aware of this problem. They may have a workaround or might make the change for you.
Another problem area is with initialization. A number of components will attach a handler to the body.onLoad() cleint-side event of a page to perform initialization. The problem occurs when the component is not well-behaved and or just plain dumb. In this case, it will either over-write an existing handler defined by some other component or even DNN itself, or just append multiple, duplicate handlers for multiple instances of a module. Again, this is something to verify through the page source.
The ID’s issued to dynamically generated U.I. objects is another problem area. Like variables and code objects, it is imperative that these U.I. objects be given unique ID’s otherwise when code tries to manipulate the object, it will fail.
The final and most perplexing problem is one of cross-compatibility. A component might do everything right, but if it sets a particular U.I. property to a certain value, and another module on the page emits script that also manipulates the same U.I. property, the result is disastrous. In this case, if changing code is not an option, the only solution is to not have the modules on the same page.
I hope this information will be helpful in figuring out which components are suitable for DNN and which ones aren’t.