Asp.net cannot ensure there are no repeated definitions in the registered JavaScript _ Asp.net skills

Asp.net cannot ensure there are no repeated definitions in the registered JavaScript _ Asp.net skills

In ASP. NET 2.0, we use some methods whose names start with register to register client scripts using the page. clientscript attribute (that is, a clientscriptmanager object.

 

How to avoid conflicts theoretically
Let's first explain why we should register the script like this, instead of using response. Write to directly output the script. For example, you use three dropdownlists to create an input date region, representing the year, month, and day respectively. Then, to prevent users from entering/02/31, therefore, you decide to cascade the three dropdownlists, that is, with the input of the year and month, the daily options will be changed. At this time, you can write some JavaScript to implement cascade. For example, you can define a JavaScript function named updatedaterange () to update the dropdownlist, and then directly put the Javascript into the C # string, and use response. write output. This code will work very normally until you have to enter two dates on one page.

On the page that requires two dates, copy and paste the three dropdownlists, and copy and paste the JavaScript code output, then, the corresponding changes are made based on the two IDs. As a result, a group of cascade nodes cannot run normally. You can view the HTML output from the server. Why ?? There were originally two updatedaterange () functions. So you change updatedaterange () to updatedaterange (yearcontrolclientid, monthcontrolclientid, datecontrolclientid), and delete JavaScript to output only once. At this time, the same function is used for any group of connections, they enter the dropdownlist according to the call time. clientid.

One day, you decided to encapsulate the cascade into a usercontrol. To do this, copy and paste the three dropdownlists and Javascript into usercontrol, copy the reference of usercontrol back to the original call. After the busy schedule, I found that the page with two date inputs had another error. The original updatedaterange (yearcontrolclientid, monthcontrolclientid, datecontrolclientid) was repeatedly output, because two usercontrols are placed on the page, JavaScript is output twice, and there is no way to reduce the number of output times.
Http://www.knowsky.com
At this time, you can use page. clientscript. registerclientscriptblock to solve the problem. It determines whether the script has been repeatedly registered through the type and key parameters, and the script that has been repeatedly registered will only be output once. Why do we need two parameters: type and key? Previous ASP. net 1. similar functions of X have only one key parameter, which may cause two different controls to use the same key to register their own scripts, as a result, the successful output of one control script will inevitably suppress the output of another control script. With the type parameter added, each control uses its own type as the identifier, which effectively avoids registration conflicts.

Why cannot we avoid conflicts?
For this question, Let's first look at the way in which JavaScript defined in ASP. NET is named. Generally, the names of private global functions or variables start with double underscores (_ dopostback), for example, webpartmanager's _ WPM on the client. Public or protected global functions or variables generally seem to use the Pascal naming method as C # does. For specific examples, you can use reflector to look at the JS files in the system. Web. UI resources.

For the time being, we assume that this naming method is correct, and then mimic the practice in the control developed by ourselves. As a matter of fact, many control developers have indeed done this. You can see the functions or variables with names starting with double underscores in many professional controls, this can at least avoid conflicts with the functions or variables registered by the control user on the page, because the functions or variables registered on the page usually adopt simple naming methods.

If we want to create a floating context menu, that is, when you move the mouse over an HTML element, the floating menu automatically appears. When the mouse leaves the element and is not on the menu, the menu disappears automatically. To facilitate user operations, we allow the user to move the mouse a little away from the menu area, so we define that the menu disappears after the mouse leaves the menu area for a few times, the time is stored on the client in the Variable _ disappearafter. This control does not seem to have any problems until you put it and ASP. the built-in Menu Control of NET 2.0 is placed on the same page, because the menu control also has similar functions, in addition, in the same way as our control, the menu control selects to save the time variable in a variable named _ disappearafter.

Now, as a user of the ASP. NET Framework, the Framework does not declare that the name of this variable is not allowed to be used. If I use it, of course, it can be considered as a framework error. Brad Abrams wrote a book 《. net Design specifications/Framework Design Guidelines: Conventions, idioms, and patterns for reusable. net libraries, but it does not mention the JavaScript and CSS specifications, it seems that in ASP. the JavaScript and CSS used in. NET are trivial and cannot be trivial, so they are not worth mentioning.

In fact, since ASP. Net allows different control designers on a page to introduce different JavaScript and CSS, you must provide a way to manage potential naming conflicts. For JavaScript, we can consider using ASP. net Ajax namespace to avoid conflicts, the next generation of Visual Studio and ASP. net will be built in ASP. net Ajax support, so the Javascript used by its built-in controls should also have namespace, which effectively reduces the probability of conflict. As for CSS naming conflicts, it is not a good solution for the time being. You can only rely on the control designer's habits. You can consider attaching a namespace to your control root element to differentiate them, this is also a way to reduce the probability of conflict.