I have a situation where
User can enter multiple prices for an item
All data is kept in datatable or datasets inside viewstate until the
form is saved
All add/update/deletes are performed in viewstate again
Griviews are placed inside update panels to show these operations
Problem I am having right now is that my webforms have gone really slow due to many update panels on the page, page size is touching about 800 KB due to all viewstate information.
Is there a way I can replace the updatepanel and gridviews altogether with a different approach ?
How can I replace current situation with
JQuery ?
What would be the implementation steps (not code just steps) to setup my current task with JQuery ?
You really shouldn't use ViewState for that. Consider storing your DataTables and DataSets in session state instead.
Related
I am using framework 2.0, and I don't understand how the datagrid and the datasets works after doing a postback. In msdn says that there's no need to do a databind again if the request is a postback. But my question is: how the datagrid shows again the records if there is no databind? I supose that asp.net saves in a cache the query results, but I am not sure. Please tell me what is the mechanism that .NET uses to accomplish it.
I have a large query result (hundreds), paginated each 50 records, and I want to avoid doing the same query every time the user select the next 50 records.
Thanks in advance.
The answer to this is the viewstate. The whole displayed grid is stored in the viewstate and it is this that persists across postbacks.
That is the grid is defined on the initial page load and stored in the viewstate. When the user clicks a link/button to postback the form the viewstate is then decoded and is available for use again. Therefore you don't need to rebind the grid. However said there are some caveats to be aware of.
ASP.NET saves your previous values into ViewState, so they aren't get lost between postbacks.
But in your case you're talking about pagination, the new records. If you're retrieving them at first request, maybe you can store them at viewstate but it's not a good idea. Your page will be served very slow if you have much records.
If your clients getting the same data every time, and the current data changes are not important while showing data, maybe you can cache it with asp.net's caching mechanism.
Viewstate is the magic word :P
ASP.NET WebForms is all about ViewState.
The concept is basically that ASP.NET is storing the information in a hidden input element on your page and then automatically retrieving it server side using postbacks, which posts the form (wrapped around your whole site) back to the server.
I have a lot of web controls created dynamically in an ASP.NET page. In certain postback scenarios (when I click a LinkButton), I want to skip the loading of the old tree of web controls and immediately generate the new tree. Unfortunately, when I generate the new tree, the viewstate of the old tree is loaded into it.
I want to be able to disable the viewstate loading process for this specific scenario, but after the new tree is loaded, the viewstate should work normally.
I've already solved part of the problem, by overriding the LoadViewState method of the web controls, but, unfortunately, this disables the viewstate specific for the control, not for his children too (textboxes, buttons etc.).
Is it possible?
Thank you.
You can try creating the new tree after the viewstate has been loaded, e.g. in Page_Load.
You can do this programatically by clearing the contents of the tree before binding the new data to it. It should be somehting along the lines of
tree.nodes.clear()
and then you just go on as if the tree is empty and add you data by either bounding it or by adding the nodes programatically with
tree.Nodes.Add(New TreeNode("name of node"))
now for regular controls which I gather you are using you will run into a whole host of problems if you don't use viewstate. You can remove them from the control tree in a similar fashion using controlname.controls.clear. Now is you problem primarily the appending of these contorls or is it that you don't want to carry the burden of viewstate? I suggest that if it's the latter that you clear your controls programatically and store viewstate server side somewhere so that it can be loaded from memory instead of using your bandwidth.
As for dynamical loading of controls you will need to ensure tha tyour new controls carry different ID's for them. What I've done in one of my apps is actually keep the old controls, make them invisible and clear the viewstate then on the next call I actually remove them from the tree.
I have answered it here:
How to load a page with its default values after a postback
I'm using a Gridview to hold records that user can click on the checkbox in each record for indication that he/she want to save that record(after editing the data) and user can select as many records as they want and save them all at once.
In the code behind, I'll loop thour the gridview and look for the checkbox to save the record. If I disable the Gridview's view state. I can't loop it but if i enabled the gridview's viewstate then the gridview view state can go as high as 1mb and beyond.
what will be the best way to reduce the viewstate on this girdview control or is my approach is wrong?
If you can't reduce the size of your viewstate you could try an alternate solution. You can store your viewstate on the server. This blog post shows how to implement this:
Reducing the page size by storing ViewState on Server
I've implemented something similar to this on a page that had a huge viewstate and it worked great. I would try to optimize the viewstate before moving to something like this since it is creating a bit of overhead.
I think I used this article (it's been a while) and had to modify it for SQL as this uses the filesystem:
Persisting View State to the File System
If you're open to the idea you might want to consider implementing custom paging to reduce the number of records returned. Perhaps start with the default paging but that returns all records. If you want better performance custom paging is the way to go.
Some helpful material:
Efficiently Paging Through Large Amounts of Data
GridView ObjectDataSource LINQ Paging and Sorting
Improve GridView Performance by Delegating Paging to SQL Server
I agree with Alex. You could also ues a temp table to hold the data. I used this scenario on a project and it works fine. You could also use caching, but again that's puting the load on the web server (unless you have some sort of distributed caching).
Is there a way to avoid postbacks with gridview every time a row is added to it?
In other words, can I store the DataTable on the client and pass it on to the server control when I am done to save, rather than do postbacks every time the row is added?
I searched and searched....all I could find was web services, JSON, and I have a feeling it's redundant here...it's a simple task I am sure everyone had to do at some point.
Can anyone shed some light on this?
There is no avoiding postbacks if you're dealing with a standard ASP.NET GridView that utilizes ViewState.
You can however, disable ViewState and manually (programmatically) render the control on every page load. This will let you control every aspect of row creation/removal/updates, but you'll have to do it all manually. And yes, you'll utilize AJAX to read from or update on the server.
I don't konw of anything that lets you do that with the gridview out of the box, except the UpdatePanel, but that doesn't really count. If you want to implement I a full AJAX grid I would look into using the ListView Control, which will give you much more control over the resulting html.
Heres a great article from MSDN Magazine http://msdn.microsoft.com/en-us/magazine/cc337898.aspx
What choices do I have for creating stateful dynamic content in an ASP.Net web site?
Here's my scenario. I have a site that has multiple, nested content regions. The top level are actions tied to a functional area Catalog, Subscriptions, Settings.
When you click on the functional action, I want to dynamically add content specific to that action. For example, when Catalog is clicked, I want to display a tree with the catalog folders & files, and a region to the right for details.
When a user clicks on the tree, I want a context sensitive details to load in the details region (like properties or options to manage the files).
I started with UserControls. They worked fine as long as I kept loading everything into the page, and never let one disappear. As soon as one disappeared, ViewState for the page blew up because the view state tree was invalid.
(I didn't want to keep loading stuff into my page because I don't want the responses to be too huge)
So, my next approach was to replace my dynamic regions with IFrames. Then instead of instantiating a UserControl, I would just change the source on my IFrame. Since the contents of the IFrames were independent pages I didn't run into any ViewState problems.
But, I'm concerned that IFrames might be a bad design choice, but don't fully understand why. The site is not public, so search engines aren't a concern.
So, finally to my question.
What are my options for this scenario? If I choose an Ajax Solution (jQuery), will I have to maintain my own ViewState? Are there any other considerations I should take into account?
Controls that are added dynamically do not persist in viewstate, and this is the reason that it doesn't matter if you use AJAX or iframes or whatever.
One possible work-around is to re-populate controls on postback. The problem with this, is the page life-cycle (simplified) is:
Initialize
LoadViewState
Load Postback Data
Call control Load events
Call Load event
Call control events
Control PreRender
PreRender
SaveViewState
Unload
What this means is the only place to re-add your dynamic controls is Initialize -- otherwise posted data (or viewstate information) is not loaded into that control. But often, because Viewstat/postback data isn't available yet in Initialize, your code doesn't have the information it needs to figure out which controls need to be added.
The only other work-around I've found in this situation is to use a 3rd party control called DynamicControlsPlaceholder. This works quite well, and persists the control information in viewstate.
In your particular case, it doesn't seem like there are that many choices/cases. Is it practical just to have all the different sets of controls in the page, and put them inside of asp:placeholder controls, and then just set one to visible, depending on what is selected?
Some other options:
Content only appears to be dynamic. You load enough controls on the page to handle anything and only actually show what you need. This saves a lot of hassle messing with view state and such, but means your page has a bigger footprint.
Add controls to the page dynamically. You've already been playing with this, so you've seen some of the issues here. Just remember that the place to create your dynamic controls for postbacks is in the Page_Init() event, and that if you want them to be stateful, you need to keep that state somewhere. I recommend a database.
you've got a number of different options, and yes, IFrames were a bad design choice.
The first option is the AJAX solution. And with that there's not really a viewstate scenario, it's just you're passing data back and forth with the webserver, building the UI on the fly as needed.
The next option is to dynamically add the controls you need for a given post, everytime. The way this would work, is that at the start of the page life cycle, you'd need to rebuild the page exactly as it was sent out the last time, and then dump out all the unneeded controls, and build just those that want.
A third option would be to use Master pages. Your top level content could be on the Master page itself, and have links to various pages within the website.
I'm sure given enough time, I could come up with more, but these 3 appeared just from reading your problem.
dynamic controls and viewstate don't mix well, as noted above - but that is a Good Thing, because even if they did the viewstate for a complex dynamic page would get so bloated that performance would diminish to nil
use Ajax [I like AJAX PRO because it is very simple to use] and manage the page state yourself [in session, database tables, or whatever works for your scenario]. This will be a bit more complicated to get going, but the results will be efficient and responsive: each page can update only what needs to change, and you won't be blowing a giant viewstate string back and forth all the time