asp.net
It is well known that when writing Webcustomcontrol, it is very common and important to inherit the attributes of the WebControl base class and its Attributes.cssstyle attributes. But these two important attributes, if the use of improper development will bring an inexplicable efficiency problems.
Because of the flexibility and incompleteness of HTML, the WebControl base class does not fully represent all tag attributes and CSS attributes provided and supported by HTML elements (of course, due to the compatibility of different browser, it is impossible to provide complete properties). And because a lot of HTML tag attributes and CSS properties are very uncommon, very little or rarely used, if you want complete support, it will become a burden of WebControl. So attributes and Attributes.cssstyle are good solutions to this problem, and of course these two properties support any legitimate custom key/value pairs, in addition to the HTML tag attributes and CSS properties that are expected. The question to be discussed here is the support for a custom key/value pair.
The type of the Attributes property is a attributecollection, a natural thing, but I don't know how, but the AttributeCollection constructor needs a statebag parameter:
Public attributecollection (StateBag bag)
{
This._bag = bag;
}
As a result, attributes and Attributes.cssstyle may be saved in ViewState, and in fact ASP.net will actually save the contents to viewstate in the default.
This kind of design really is lets the person feel inexplicably, in everybody to the ViewState efficiency question discussion, felt viewstate really is the chicken ribs, uses to maintain some server status and the data lets everybody feel convenient also to forget. But it is crazy to put the UI-related content into the viewstate.
The following is a case of viewstate after you have defined some customizations using attributes:
///Analysisreport custom controls define some custom content
Attributes and Attributes.cssstyle were automatically saved to the ViewState, in addition to the viewstate volume, the load postback burden increased at the same time. The loadstate cost of the page postback in this case, as shown below:
In fact, when I was writing controls, I never thought about keeping attributes and Attributes.cssstyle, and I didn't want to use the data again. And this default save to ViewState behavior can not be customized (at least I have not found), It was later thought that in the ASP.net page lifetime, SaveState ended up in PreRender, so attributes and Attributes.cssstyle used in render events would not be saved to viewstate.
To modify the code:
protected override void OnPreRender (EventArgs e)
{
This. attributes["abc"] = "123";
This. attributes.cssstyle["Abc-style"] = "123-style";
Base. OnPreRender (e);
}
to the following form:
protected override void Render (HtmlTextWriter output)
{
This. attributes["abc"] = "123";
This. attributes.cssstyle["Abc-style"] = "123-style";
Output. Write (Text);
}
The attributes and Attributes.cssstyle will no longer be saved to the ViewState, the Analysisreport above is modified by the above example, the binding of the same data will work as follows:
The cost of loadstate is also greatly reduced, and its cost is:
