ASP.NET Web Forms Weaknesses - Last Example
(Page 5 of 5 )
Well, let's take a look at another sample with a little complication below:
<%@ Control Language="C#" AutoEventWireup="true" %>
<asp:TextBox runat="server" ID="textBox" />
<script language="javascript" type="text/javascript">
var counter = 0;
function increase()
{
document.getElementById("<%= this.textBox.ClientID %>").value = (counter++);
window.setTimeout(increase, 500);
}
increase();
</script>
The above JavaScript code is aimed at adding 1 to a counter every 500 ms, and showing the value of the counter at the TextBox control. However, in a large and complex project, with the JavaScript code on the pages getting more and more complex, we'd better transfer the scripts to individual .js files and refer to them in the pages. As is well known, using individual .js files facilitates code management and improves performance.
If you put the JavaScript code directly on the pages, every time the page is loaded, it will need to download these JavaScript codes. The .js files can be buffered, so that they only need to load one time. The script files can be utilized again and again, which decreases the communication between the client side and the server side so that loading speed is increased and performance is improved.
Now here is the issue. To correctly refer to the DOM element generated by the Server Control at the page, we have to use the <%= %> mark to output the property 为 ClientID. However, the <%= %> mark can not be used inside the .js file! This example represents another kind of "client-side ID pollution" caused by using WebForms.
So, what should we do with the above puzzle? The answer is to only extract the invariable parts into .js files while leaving the variable parts (such as the client-side ID of the server control) on the page. Also, another typical solution to this is to use the Component technique, a good example of which is the ASP.NET AJAX Control Toolkit Extenders. For brevity, I won't list related code examples; you can check these out yourself.
Over a period of time, the Rails framework has become popular, especially with the combination known as Ruby On Rails. So, within the .NET community there also appeared a Monorail, and the voices criticizing Web Forms have become louder and louder. With Microsoft itself producing the new ASP.NET MVC framework, Web Forms critics become even more critical. Well, will Web Forms quit the stage and become obsolete? Let's look more closely into the ASP.NET MVC framework and find out the answer.
Before making comments on ASP.NET MVC architecture, it's necessary to say a few words about it. We will begin to cover it in the next part of this four-part series.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
