ASP.NET Web Forms Weaknesses - The JavaScript Weakness
(Page 4 of 5 )
(3) Integrating JavaScript Frameworks
Another problem with Web Forms is the integration of JavaScript frameworks due to the naming conventions of rendered HTML. The page life cycle of the Web Form is too complex and features tight coupling between everything in the ASP.NET framework; furthermore, a single class is used both to display output and handle user input. So unit testing is an almost impossible task. However, today unit testing is very important in modern software development, especially when we follow agile methodologies and practices. Since the web is a stateless thing, Events, Postbacks and ViewState are not a good way to go.
As I've mentioned above, we can use Web Forms to freely control the HTML attributes and styles on the page. However, there is no doubt that we have no way (short of "hacking") to let the Web controls generate a simple ID. Here, let's take a TextBox control for example: although we specified its server side ID as txtUserName, the final client side ID might be LoginForm_txtUserName because it's within a NamingContainer whose ID is "LoginForm."
With the appearance of the component model, there also arises tons of controls. We know that one of the main purposes of controls is multi-use, which in turn requires high cohesion that does not rest upon outside factors as much as possible. Therefore, to generate a unique ID on the client side for the related server side control, Web Forms introduces a new concept-NamingContainer. Server controls inside a NamingContainer will result in a client-side ID prefixed with the NamingContainer-provided rules. In this way, the client-side ID can be made unique.
Another typical example relates to AJAX, a JavaScript technique implemented on the browser side. In AJAX-associated programming, we usually work with various DOM elements using JavaScript. In a non-Web Forms page, we can write something like the following:
<input type="text" id="textBox" />
<script language="javascript" type="text/javascript">
document.getElementById("textBox").value = "Hello World!";
</script>
However, due to the NamingContainer, when we use Web Forms-related server controls, it might be impossible to locate the textbox element (the result <input />) through the TextBox server control. To overcome this problem, the server control model introduces a ClientID property through which we can acquire the client-side ID on the server side. For example, if you put the above code inside a user control, you should write it like this:
<%@ Control Language="C#" AutoEventWireup="true" %>
<asp:TextBox runat="server" ID="textBox" />
<script language="javascript" type="text/javascript">
document.getElementById("<%= this.textBox.ClientID %>").value = "Hello World!";
</script>
When the control is put on a page, the client-side related result code should look like this:
<input name="DemoControl1$textBox" type="text" id="DemoControl1_textBox" />
<script language="javascript" type="text/javascript">
document.getElementById("DemoControl1_textBox").value = "Hello World"!;
</script>
Please take notice of the name and id property of the above <input /> element here, all of which are in relation to marks left by NamingContainer. However, because we've used the <%= %> mark on the page to directly control the ID property of the server control, we can access the corresponding <input /> element related to the server side TextBox control using client-side JavaScript.
As you've seen above, this kind of peculiar client-side ID is difficult to forecast in the design; it is just the so-called "client-side ID pollution" caused by using Web Forms.
Next: Last Example >>
More ASP.NET Articles
More By Xianzhong Zhu
