ASP.NET: Intercepting and distributing runtime dynamic creation controls Sunday, December 07, 2003 3:06 AM
First, problem
In the B / S system-based .NET distributed solution, I am currently involved in the design, you need to perform certain performance optimization on the Web interface service layer to meet the project operational demand for ensuring the terminal browser in use low-speed network (such as 33.6 / The response speed of the 56kbps modem is required. Friends developed using ASP.NET should know that when we use ASP.NET, we also pay a certain bandwidth and performance cost, such as more typical examples are inappropriate use of ViewState. Therefore, many performance optimizations of the interface service layer are articles on ViewState.
For example, there is a large number of Web Form interface components in our solution, where a large number of DataGrid and other data list display controls are applied. These components use viewState to save the data of the list itself. If you disable its viewState to reduce the amount of page transfer data, you must rebound when the state of these components (in particular in which dynamically created sub-controls) must be rebounded at the page postback (of course, at this time Select the server-side buffer technology to reduce the pressure on the background database).
According to my experience, use DataGrid as an example, usually there are several kinds of usage:
1. Display a set of data and allow the user to add, delete, modify the operation. In general, command controls for adding new data are independent of list controls and static statements. However, command controls such as deletion, modification are basically created when the data control is binding data.
2. If users choose to create new data, our use case is required to guide the user to a separate page for creating a new data item. That is, the data display page does not rely on the current state of the data control when performing this. In this case, it is not necessary for the original viewState that requires the data control, and does not need to be rerouted (will be turned to other pages).
3. If the user selects the deletion of a data, our use case is required to refresh the data list to reflect the results of the operation. Since the data in the data control will be updated, it does not require its original ViewState (but actually, seeing after analysis), because it needs to be re-data binding after executing the requested operation.
4. If the user selects the update of data, our use case is required to transfer the user to the page used to modify the selected data item. In this case, the original ViewState of the data control is not required because it is turned to other pages immediately. The data will be re-acquired and bind to the data control when the data is completed back to the list display page.
It can be seen that in the case where there is no need to place data editing (compared to a bandwidth application environment), it is basically no need to retain the viewState of the data control after each page is generated. But this immediately brings a problem. If Postback is triggered by "Dynamic Create Controls in Data Bindings", the control of this trigger event must still exist in Postback back Page_Load, and to make this control return at Postback Also, you only have two options: or if you reserve the viewState of the data control allows it to automatically restore the original control combination status, or you resin the data, you can create it in this process (* Note: If you re-data When the data changes or deleted, it is possible to forward it to the wrong dynamic control! It is best to manually create the control setting ID of the dynamically created to enable it to correspond to the relevant data item).
To delete a data as an example, if the user presses a delete button on a row, the event is processed by postback to the background page, the ASP.NET page processing engine resolves the button that triggered the event and forward the event to the event. Its event handler. In the event handler, we only need to know which line to delete (or simply say, what is the ID of the data to be deleted) is enough. For this information, you or want to transfer the status of the entire data control through ViewState, or rebound when Page_Load - Everything is for an ID that can locate the operation target! (To be renewed ... Welcome to comment! If there is a good way, I will no longer write :)
Second, the idea
Third, program
Fourth, after
Feedback
# 回:: ASP.NET: Intercept and distribute the runtime dynamic creation controls 12/7/2003 4:14 AM BY
Bigvan
Follow ING
Always feel. NET's resource consumption is too much, a bit bad.
Although the project I did was not high, users also complained that the new system was slower than the old system.
# 回: ASP.NET: Intercept and distribute the event of the runtime dynamic creation control 1/17/2004 2:58 PM BY
SBHU
This article is very well understood, how to store DataGrid in useless data in ViewState (sometimes it is true) card, everyone knows that DataGrid will store all the data in the table in ViewState, this will Leading ViewState is very large; as compared with this forum, the viewstate takes more than 65K, more waste.
If you just simply set the DataGrid's EnableViewState to false, then many events, such as sorting, change, etc., will not be triggered, then don't you get lost? In fact, in DataGrid, there is a child control for rendering data: system.web.ui.WebControl.dataGridtable, unfortunate, I didn't find its instructions in MSDN, but when I tracked DataGrid, I found it A child control is the above Class (of course, this is what I know later, 嘿嘿). Everyone can take a look at the type of objects in SaveViewState, plus all values in DataGrid.ViewState, will not find data saved in ViewState, then what causes viewstate, what is Data from the data source in ViewState?
The answer is in DataGrid's sub-control (this darkman's existence is really can't stand the feelings). So, if you don't need to store data from these data sources in ViewState (for example, in order to speed up the speed, or custom paging), we only need: DataGrid.Controls [0] .enableViewState = false, is OK.
Oh, I didn't take the original word, I am afraid that I can't turn it up, but it is true that it is like this. In the last few words, I really made me ruthless, I think many people are like this, huh, huh. Bamboo, do you think this article doesn't value?
============================================================================================================================================================================================================= = If I do not use whether it is DATALIST or REAPTER?
DataList.controls [0] .enableviewState = false
Reapter.controls [0] .NableViewState = FALSE
=============================================================================================================================================================================================================
I found a super good article today, shared with everyone; see if the board is home, it is very helpful.
Thomas Skovsende
Hi there!
The Scenario is this:
I have alot of datagrids with data in them. This makes my viewstate Rather
Large (Upto 1MB), SO i Have Tried to Find Ways To FIX THIS.
I First Tried Storing My ViewState In A Session Instead by Overriding
SavepagestateTopersistencemedium / loadPagestateTopersistencemedium. This
Works Fine - Except When People Start To Open More Than One
Window (ViewStates Starts To Overwrite Eachother, Which Will Result In AN AN
INVALID CAST.
Then I got the idea to make a new datagrid, inherited from the original
DataGrid - and Then Override The LoadViewState / SaveViewState Methods. (AND
Fetch The Data from The DB on Every Request
But While Doing this, I Discovered That Those Methods Only Are Responsible
For Saving ViewState for themselves - NOT Their Children (The DataGridTable
In The DataGrid - this is done by an undocunted method in Control Which
Is Defined As:
Internal Object SaveViewStateRecursive ()
The Problem Here Is That IT IS Not Virtual - SO I Cant Override It and Stop
The Framework from Storing The ViewState of The Actual Data in The DataGrid! You might argue That i shop Disable The Saving of ViewState and Code
Everything Manually - Well - TBH, I Find It Silly That I Have to make alot
Of extra code (and Ny That Introduce Possible Bugs), When All It Would Take
To Solve My Problem is to make saveviewstaterecursive () Virtual SO i CAN
Override it. if That Happend, I Would Just Override It for My Custom
DataGrid - ViewState Wouldnt Be Saved for My Grid, And no Bugs Would Be
Introduces (Less Likely Anyway!)
I Might Be Missing Some Obvious Solution To My Problem, But if Not I Would
Love an Argument for SaveViewStateRecursive () Not to Be Virtual. I am Aware
That there is a slight Performance Overhead, But I Would Say That IS
SO Little That It Doesnt Matter Much!
Best regards,
Thomas Skovsende
Thomas Skovsende
* Sigh *
Sometimes I Just Hate Being A Developer - After Battling with this qu.
For a few Good Hours, The Obvious Solution Appears:
Protected Override Object SaveViewState ()
{
Controls [0] .NableViewState = false; // disable viewstate for the
DataGridtable - Hardcoded - But Works for Now!
Return Base.saveViewState ();
}
Ahh Well .. another case of "stupid development" ...: o)
Best regards,
Thomas Skovsende
# 回: ASP.NET: Intercept and distribute the event of the runtime dynamic creation control 1/17/2004 4:14 PM BY
JGTM'2004
@HBSU:
This method is used to save the viewstate is really good, thank you for your resources! Unfortunately, I haven't had time to complete this article, because my idea is done in the direction of Command Dispatching (that is, it can be properly not using the command request of the data column accordingly). However, for most friends, the method in the article should be enough (but you need to deal with DataGrid, maybe it is more troublesome).
# RE: ASP.NET: Intercept and distribute the runtime dynamic creation control 11/23/2004 5:01 PM By
Zpisgod
In fact, you don't have to get DataGrid, and write the previous sentence in Pageload:
