Details determine the success or failure of the Butterfly Effect in ASP. NET

Preface

The advantage of ASP. NET is that each control is independently responsible for its internal logic. This is a good thing, because it solves the problem of high coupling of ASP processing logic. However, this is a price, that is, the introduction of ASP. NET page lifecycle. With the multi-layer nesting of controls, the complexity of the application increases, and we are stuck in the quagmire again!

Problem

Actually, thisArticleI wrote down the question two months ago, but I never thought about writing it. Today I spent a few hours in this quagmire, so I decided to jump out of the quagmire and write the article first, skip to continue solving the problem. The problem is as follows:

Use MS Ajax 1.0 beta2 + 2.0 CTP to create a project, and put the ajaxcontroltoolkit. dll of beta2 in the bin.

Put an accordion, put several accordionpane, and set cssclass.

In page_load, use page. loadcontrol to load a usercontrol and add it to the page.

Then we found that the control in usercontrol could not trigger the event normally and fell into the quagmire ......

First of all, it should be noted that if the usercontrol in step 1 is normal, it means that the problem occurs in scriptmanager or accordion.

Body

Do you want to know what went wrong? Let me talk about the ASP. NET page lifecycle.

Because the lifecycle is divided by stages and tasks are completed step by step in different stages, each of our operations is related to stages, and some operations can only be performed at specific stages, some operations in different stages may lead to different results. Of course, Ms wants to eliminate the differences between these stages as much as possible, such as allowing an operation to be executed in as many stages as possible, and minimizing the different results caused by operations in different stages. However, this cannot be done completely. For example, we all know that viewstate read and write is restricted only in some stages, so the control attributes dependent on viewstate are subject to the same restrictions.

The read and write operations on control properties are limited by stages, which is acceptable, right? This is only a layer of dependency. After the dependency is promoted, the situation becomes more and more complex, and the reason for the restriction is buried at the bottom layer. Then we find that the complexity problem lies in ASP. net, a well-structured system that has not been invented yet.

As developers of controls or components, we certainly have the obligation to eliminate stage differences, so that downstream developers can face lower complexity, and we do our best. Each layer of the control contains this kind of effort and promises the lowest possible stage difference. However, in order to make the controls look simple and easy to use, we cannot completely record these differences in the document. We try to conceal the details, as we do when the controls are encapsulated layer by layer. The underlying documentation does not tell me the difference. Of course, I do not need to write the document at this level. The differences mentioned in the underlying documentation are what I try to make up for, even if not, this layer of documents is not written. As a result, the document is like a mythical legend that changes with the generation of data, and no one knows that this control depends on some underlying stage differences.

People who have developed controls know that sometimes we have to build controls that look the same in different ways based on the actual situation. For example, the simplest data control has a difference in whether to build PostBack. If it is not PostBack, you need to build it at databind and save the data to viewstate. If it is PostBack, you can directly build it based on viewstate, if you encounter databind after PostBack, you need to clear the original build and re-build based on the new data. Some more complicated controls will also be built in steps. By default, in order to eliminate the stage differences between users, some build steps will be executed as early as possible at init, in addition, the construction steps are postponed to prerender as much as possible, while in the middle part, the changes are minimized for users to perform operations. However, things are not that simple. Some operations of the user (usually accessing a property) depend on the completion of a build step. Therefore, once these operations occur, the specific Build Steps originally executed in prerender must be performed in advance. When such operations are performed several times in different stages, the build steps are already scattered in various stages of the page lifecycle.

Building steps may be scattered at various stages of the page lifecycle, which is a serious problem for the control designer. This means that he must ensure that any build step is executed at any stage without any difference, of course, this cannot be done, so we need to introduce other mechanisms to reduce this difference. The complexity arises. As the complexity increases, the control designer will become increasingly unable to ensure a low level of difference, as a result, the control user suffers. If the control user encapsulates the control and tries to reduce the stage difference, then the disaster will happen ......

Result

I spent a few hours in the quagmire and wrote this article. Of course the problem has been solved.

If headercssclass or contentcssclass is set for accordion, a problem may occur. However, if the above two attributes are added for accordionpane, no problem will occur. In this case, you can use reflector to viewCodeThe result shows that accordion checks whether each accordionpane has these two attributes. If not, set accordionpane to be the same as its own. This is called when accordionpane is set. ensurechildcontrols () is a method that will lead to the construction step to be executed in advance, so the order of control building is changed, not only the internal order of accordion is changed, but the entire page is changed. Because the control IDs are automatically assigned in order, including my usercontrol, changing the building order means that the ID changes, which is equivalent to changing the entire control tree. Of course, events cannot be triggered normally.

The final solution is to specify the ID for my usercontrol. it took me so many hours to find that I had done something stupid. Early in the morning, I opened the trace to see the control tree and I should be able to see the changes in uniqueid.

Summary

Although this problem does not seem to be a good example, it should be able to find the source of the problem as soon as the trace is opened, but it actually reveals ASP. the "Butterfly Effect (Butterfly Effect)" in the Net Framework-any slight change with the increase in complexity will lead to a huge global change. In the design of ASP. when it comes to net, Ms may also be thinking about decoupling. In simple cases, this is indeed decoupled. However, in complex cases, it is just the opposite. This is really ironic.