The details determine the success or failure of ASP. The Butterfly effect in net

asp.net Preface

Asp. NET's advantages I have said many times, that is, the individual control of their own internal logic, this is a good thing, because it solves the original ASP to deal with the high degree of logic coupling problem. However, this is a cost, that is, the introduction of the ASP.net page life cycle, with the control of multi-layer nesting, application complexity increased, we again into the mire!

　　Problem

In fact this article topic I wrote down two months ago, but has not wanted to finish it, until today I soak in this mire for several hours, so decided to first jump out of the mire to write the article finished, and then jump in to continue to solve the problem. The problem is this:

Create a new project with Ms AJAX 1.0 BETA2 + 2.0 CTP and put Beta2 AjaxControlToolkit.dll in the bin.

Throw a accordion, place a few accordionpane, set the CssClass.

Use Page.LoadControl to load a UserControl in Page_Load, and then add it to the page.

Then found that the control within the UserControl can not normally trigger events, into the mire ...

First of all, if only the 3rd step that UserControl is sure to work, it means that the problem arises in ScriptManager or accordion.

　　Body

You want to know what the problem is? Let me tell you something about this asp.net page life cycle.

Because the lifecycle is phased, the tasks are completed in stages, so each of our operations is phase-dependent, and some operations can only be performed at a specific stage, and some operations at different stages can lead to different results. Of course, Ms wants to try to eliminate the differences between these phases, such as allowing an operation to execute at as many stages as possible, and minimizing the different results that are raised during different stages of operation. However, this cannot be done completely, for example, we all know that viewstate read-write is restricted to only certain stages, so the control properties that depend on ViewState are similarly restricted.

Control property Read and write is subject to a stage limit, which is acceptable, right? Because this is just a layer of dependencies. With the extension of dependency, the situation becomes more complex, the reasons for the restrictions are buried more and more, and then we find that the problem of complexity arises in the asp.net system, and the silver bullet that eliminates this complexity has not been invented.

As a developer of a control or component, we certainly have an obligation to eliminate phase differences, to lower complexity for downstream developers, and indeed to do our best. Each layer of the control encapsulates this effort and promises up to the lowest possible stage difference. However, in order for the controls to look easy to use, it is not possible to record these differences completely in the document, we try to hide the details, we do this when the control is encapsulated in layers. The underlying document doesn't tell me the difference, and I certainly don't have to write to this level of documentation; The underlying document mentions the differences, and I try to make up for it, even if it's not too good to make up, and not write to this level of documentation. So the documents are like myths and legends that change from generation to generation, and no one finally knows that the control relies on some low-level phase differences.

As anyone who has done control development knows, sometimes we have to build the same controls in different ways, depending on the actual situation. For example, the simplest data control will have a postback build difference, if it is postback, you need to build and save the data to ViewState at DataBind time, if postback is built directly from ViewState, If you encounter databind after postback, you need to clear the original build and rebuild it against the new data. A few more complex controls, there is also a step-by-step build, by default, in order to eliminate phase differences in the consumer, part of the build steps are executed as far forward as possible to Init, while the other build steps are deferred to PreRender as much as possible, and the middle section minimizes its own changes for the consumer to operate. However, things are not that simple, and some of the actions of the consumer (usually access to a property) depend on the completion of a build step, so that once these actions are made, the specific build steps that were performed in PreRender will be executed ahead of time, when such operations occur several times in different stages, The build step is already scattered at all stages of the page life cycle.

Building steps may be scattered across the lifecycle of the page, which is a serious problem for the control designer, this means that he wants to make sure that any one of the build steps is executed at any one stage without any difference, of course this is not possible, and then there are other mechanisms to reduce the difference, and the complexity arises, Next, as complexity increases, the control designer is increasingly unable to ensure a lower level of variance, which is the case for the control user, and if the control user then encapsulates the control and still attempts to reduce the stage variance, then the disaster occurs ...

　　Results

I spent hours in the mire, writing this article, and of course there was a result.

If the accordion set Headercssclass or Contentcssclass, then there will be problems, but if you add the above two attributes for Accordionpane, there will be no problem. This situation, of course, by using reflector to view the two classes of code to solve, the results found that accordion will detect whether each Accordionpane have set these two properties, if not the Accordionpane set to the same as their own. This is called when the Accordionpane is set. EnsureChildControls (), which is a method that causes the build steps to execute ahead of schedule, the order in which the control is built changes, not only the order of the accordion interior changes, but the entire page changes. Because the ID of the control is automatically assigned in order, including my UserControl, the change in the build order means that the ID changes and the entire control tree changes, and the event certainly does not trigger correctly.

The final solution, of course, is to specify the ID for my UserControl. It took me so many hours to discover that I had done a stupid thing, and that early in the morning, the control tree should be able to detect uniqueid changes.

　　Summarize

Although the problem does not seem like a good example, since opening trace should be able to find the source of the problem, it actually reveals the "Butterfly Effect" (butterfly Effect) within the ASP.net framework--as the complexity increases, Any slight change can lead to a huge change in the overall situation. In the design of ASP.net, Ms may also be thinking decoupling, in the simple case of this thing is also decoupled, but in the complex situation is just the opposite, it is really ironic.