The Isolation of Web Parts from Other Web Parts
This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.
Because the Web Parts you build are included in the Document Object Model of the Digital Dashboard along with other Web Parts, there is a high possibility of script collisions. Anytime you create a Web Part that contains client-side script, you must isolate that Web Part from the other Web Parts on the page. Any of the following cause an error in the dashboard:
- Functions that have the same name in multiple Web Parts
- Objects that have the same names in multiple Web Parts
- Variables that have the same name in multiple Web Parts
When you isolate a Web Part, script functions and event sinks in that Web Part run as though they are the only scripts on the page — function names do not conflict with function names in other Web Parts, and event sinks do not conflict with other event sinks on the page. In addition, HTML IDs in the isolated Web Part do not conflict with HTML IDs in other Web Parts on the dashboard, and any ID referenced in a script uniquely identifies an element in the content of that Web Part.
If you are building a Web Part that will not be isolated, that Web Part's module-level variables and procedures will be part of the same page as the dashboard's variables and procedures. The variables and procedures the dashboard uses have a ddv_ prefix to reduce the likelihood of duplicate variable or procedure names, but it is a good idea to prefix your variables and procedures with the replacement token "_WPQ_" to avoid name collisions with other non-isolated Web Parts. Do not include <HTML>, <HEAD>, or <BODY> tags in your source code, because your code will be inserted into a page that already contains these tags. It is good practice to wrap your code inside procedures whenever possible and limit variable declarations to the procedural level. This eliminates unnecessary variables and reduces the potential for namespace collisions.
The Isolation of Web Parts into Frames
To fully isolate a Web Part from the other Web Parts on a dashboard, use the RequiresIsolation property. This places the Web Part in an IFrame. When you use RequiresIsolation, the request for the content comes from the client computer (instead of the server), so the Web Part can pass cookies and prompt for basic authentication. The request for content for an isolated Web Part occurs asynchronously from the rest of the Web Parts on the page. This can be useful for Web Parts with linked content that loads slowly. The downside of using RequiresIsolation is that it makes the Digital Dashboard Services Component inaccessible because of security considerations.
String Replacements that Avoid Name Collisions
If you do not want to isolate a particular Web Part but are concerned about name collisions with HTML elements or scripting functions on the dashboard, you can use the Digital Dashboard Globally Unique Identifier (GUID) service to make sure the function names and HTML IDs in your Web Part are unique.
To use the service, add the prefix "_WPQ_" to the HTML IDs and function names in your Web Part. The dashboard then performs a string search-and-replace function, converting the string to the ID of the Web Part, which makes the HTML IDs and function names for your Web Part unique within the assembled page.
Token Replacements
To make it easier for Web Parts to function in a variety of environments, dashboard factories perform token replacements.
**Note **Tokens are case-insensitive — you can use any combination of upper- and lower-case characters.
Token | Properties | Replacement |
---|---|---|
_WPID_ | Content, ContentLink, CustomizationLink, DetailLink | Unique ID of this Web Part instance. Format can vary between data stores. |
_WPQ_ | Content | Unique ID of this Web Part instance with respect to other Web Parts in the same dashboard. This can be used to qualify HTML IDs and script function names to avoid name collision. Does not vary between data stores. |
_DashboardID_ | Content, ContentLink, CustomizationLink, DetailLink | Unique ID of this dashboard. |
_LogonUser_ | Content, ContentLink, MasterPartLink | Value retrieved from ASP function Request.ServerVariables("LOGON_USER"). This value typically contains the client's Microsoft® Windows® 2000 user name (for example, adventureworks\kimy). It can be used for user identification within an intranet. This makes it possible for a URL in ContentLink that points to an intranet site to identify the client without having to be set up to delegate Windows 2000 credentials. |
See Also
Developing a Digital Dashboard Using Web Parts | Guidelines for Building Good Web Parts | Informative and Customizable Web Parts | Web Parts that Maintain a Consistent Look and Feel | Portable Web Parts