Thursday, June 01, 2006
Mastering and paging JavaScript: Problems
ASP.NET 2.0 introduced the potentially useful master and content pages, but with them it also introduced new problems for client-side scripts. The ID of each content page element is extended and qualified in one of Microsoft's obscurely documented conventions. Client-side scripts that try to use the ID values that a programmer specified will fail.
Microsoft usually gives client-side scripts a pass; ASP.NET 2.0 was designed to promote and sell server software. Client-side scripts have the added demerits, in Microsoft's eyes, of using JavaScript, a language designed by a competitor, or ECMAscript, an international standard. Their document purgers, currently in ascendance with VS (Visual Studio), have removed from distributed "Help" documents several articles and sections of articles that might reveal the client-side problems and assist in solving them. However, many articles remain available in libraries distributed by MSDN (Microsoft Developer Network) and displayed at Microsoft's web sites. Key sections of documentation are the topics "Web Server Controls," "ASP.NET Programming" and "ASP.NET Controls" under "Visual Web Developer" in the VS library and the topic "ASP.NET Server Controls" under "Creating Web Applications and Services" in the MSDN library.
The root of the client-side problems with master pages is name qualification, which occurs when a control is located within the scope of another control that acts as a "naming container." Naming containers are largely of interest with controls that generate collections of other controls--any templated control and all standard controls that use templates: Repeater, DataGrid, DataList, CheckBoxList, ChangePassword, LoginView, Menu, SiteMapNodeItem and RadioButtonList. See the articles "Web Forms Control Identification," available in both VS and MSDN, and "Referencing Controls in Web Forms Pages," available only in MSDN. The article "Client Script in ASP.NET Web Pages" says that the ID values of controls in the scope of a naming container will be extended and qualified so that they are unique on a page, but it does not say how this is done. The article warns against using the extended and qualified names in client-side script: "The formula used to generate unique IDs for child controls can change."
A master page is associated with the MasterPage class, which is derived from the UserControl class and therefore implements the INamingContainer Interface. ID values of all controls in the scope of a master page will be extended and qualified--including everything on associated content pages. The fact that a master page acts as a naming container is referred to obliquely in just a single "Visual Web Developer" article, "How to: Reference ASP.NET Master Page Content." This article says that to identify a control located on a master page, one needs "the FindControl method, using the value returned by the Master property as the naming container." An October, 2003, article from MSDN, "Web Site Consistency Made Easy with ASP.NET 2.0 Master Pages," says, "Each instance of System.Web.UI.ContentPlaceHolder within a Master Page acts as a naming container."
Most client-side scripts used with master and content pages must somehow deal with controls on their pages, but Microsoft provides no guidance for how to do this. Its documentation addresses only issues of how to identify controls in server-side code. There is no equivalent to the FindControl method available to a client-side script, yet Microsoft has been aware since at least 2003 that its master-content architecture would be incompatible with client-side scripts.
Microsoft usually gives client-side scripts a pass; ASP.NET 2.0 was designed to promote and sell server software. Client-side scripts have the added demerits, in Microsoft's eyes, of using JavaScript, a language designed by a competitor, or ECMAscript, an international standard. Their document purgers, currently in ascendance with VS (Visual Studio), have removed from distributed "Help" documents several articles and sections of articles that might reveal the client-side problems and assist in solving them. However, many articles remain available in libraries distributed by MSDN (Microsoft Developer Network) and displayed at Microsoft's web sites. Key sections of documentation are the topics "Web Server Controls," "ASP.NET Programming" and "ASP.NET Controls" under "Visual Web Developer" in the VS library and the topic "ASP.NET Server Controls" under "Creating Web Applications and Services" in the MSDN library.
The root of the client-side problems with master pages is name qualification, which occurs when a control is located within the scope of another control that acts as a "naming container." Naming containers are largely of interest with controls that generate collections of other controls--any templated control and all standard controls that use templates: Repeater, DataGrid, DataList, CheckBoxList, ChangePassword, LoginView, Menu, SiteMapNodeItem and RadioButtonList. See the articles "Web Forms Control Identification," available in both VS and MSDN, and "Referencing Controls in Web Forms Pages," available only in MSDN. The article "Client Script in ASP.NET Web Pages" says that the ID values of controls in the scope of a naming container will be extended and qualified so that they are unique on a page, but it does not say how this is done. The article warns against using the extended and qualified names in client-side script: "The formula used to generate unique IDs for child controls can change."
A master page is associated with the MasterPage class, which is derived from the UserControl class and therefore implements the INamingContainer Interface. ID values of all controls in the scope of a master page will be extended and qualified--including everything on associated content pages. The fact that a master page acts as a naming container is referred to obliquely in just a single "Visual Web Developer" article, "How to: Reference ASP.NET Master Page Content." This article says that to identify a control located on a master page, one needs "the FindControl method, using the value returned by the Master property as the naming container." An October, 2003, article from MSDN, "Web Site Consistency Made Easy with ASP.NET 2.0 Master Pages," says, "Each instance of System.Web.UI.ContentPlaceHolder within a Master Page acts as a naming container."
Most client-side scripts used with master and content pages must somehow deal with controls on their pages, but Microsoft provides no guidance for how to do this. Its documentation addresses only issues of how to identify controls in server-side code. There is no equivalent to the FindControl method available to a client-side script, yet Microsoft has been aware since at least 2003 that its master-content architecture would be incompatible with client-side scripts.
Subscribe to Posts [Atom]