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
Related
I believe this is a fundamental question regarding asp.net's way of manipulating database items. Basically the server side way of manipulating database items (using ListView or similar) is outdated due to the post back model is outdated compared to AJAX. Let's say you have forward and backward buttons on the gallery to update images from the database. You need to postback in order to update page. Clearly this could use an ajaxfied approach. I have been thinking about this long and hard and have observed most websites that uses ListView or GridView or whatever do not ajaxfy the process, probably due to the difficulty of this problem. For those that ajaxfy the page, they use the UpdatePanel, which is only "pseudo-ajax".
I would like to know do other programmers have a FULLY ajaxfied way of updating a page of a photo gallery, retrieved from database by ListView? As I said I have been thinking about this long and hard and I think there might be two approaches: First, use ListView to first populate photo gallery. On pressing forward or backword button, use jQuery's ajax method to connect to an .ashx page and use .ashx page to retrieve data items and then use jQuery to update the photo gallery at the client side.
The second way I forsee would be abandoning the ListView altogether and use a for loop in .ashx to populate gallery from the beginning. This approach unifies the initial data retrieval method and the "postback" data retrieval method, which could mean less code needed, since you do not need the aspx page at all.
My question is, what is the realistic way to fully ajaxfy the page mentioned above?
I still use code behind in my asp.net website.. but I do use ajax elements on the .aspx page
take a look at ASP.Net Ajax Control Toolkit
All the Ajax elements, with the benefit or still using code behind
So far the best way I have found would be to use jQuery AJAX to update whatever changes, although it can be much more time consuming than posting back to server and update from there
I have a couple of pages that are bulky due to the viewstate. I have following question:
is there any tool that can track viewstate of individual control on page and tell me which control is taking maxm viewstate
also can i know which controls viewstate is not being used and disable it?
There are some Viewstate Utilities listed here http://blogs.msdn.com/rextang/archive/2007/05/25/2868250.aspx. I always store Viewstate in the database rather than send it back and forth over the internet. Example Code here http://www.componentworkshop.com/blog/2009/06/27/advanced-net-storing-viewstate-in-a-database
You can turn on trace on the page and that should show how much viewstate is used for each control.
I have no good answer to your second question, but one rule of thumb I use when i develop webforms is that i set EnableViewState=false immediately after I've created an Ascx.
That way I can turn it on when I actually need it and not wonder if my databound controls uses alot of viewstate.
I have a very big problem. I am making a CRM (Costumer Relationship Management) System in ASP.NET 3.5
I have based my entire project on DevExpress.com controls and the use of UpdatePanels.
Now one of my pages, which is a central page in the whole system, contains a very big amount of possibilities and therefore a big amount of UserControls.
Now my problem is that it's getting really really slow because of the fact that UpdatePanels are reposting the entire page and not only the update panel. We are talking sometime 3-4 seconds before a popup window appears :(
Is there any way I can refactor this entire system away from UpdatePanels without breaking my neck?
Are there anyway I can optimize my use of UpdatePanels?
The ViewState is also absolutely giant.
Any good ideas are welcome...
There's no way to get around posting the entire page using UpdatePanels. In lieu of redesigning the app here are a couple things I'd try:
Disable viewstate for any controls that don't need it
Set the UpdateMode="Conditional" for your user controls. This won't get around posting the entire page but it will cut down on rendering time a little. Only the content for the specific UpdatePanel will be updated in the browser.
Make sure your user controls have short IDs. The way ASP.NET webforms names controls in the html these IDs get repeated quite a bit if you have a lot of server controls. Same goes for naming master page placeholders. I once cut a large page to half the size by renaming user controls and placeholders.
Since you're a DevExpress user, you might consider taking a little time to learn their CallbackPanel which will allow you to do asynchronous processing without the overhead of the UpdatePanel.
Alternatively (someone please correct me if I'm wrong) but if all of the postbacks are asynchronous (i.e. in an UpdatePanel), wouldn't it be theoretically possible to disable ViewState for the entire page (in the Page directive) without negative consequences? You'd have to test it completely off course, but it's worth a shot.
You'll have to replace some of the postbacks contained in your update panels with real AJAX calls, i.e. send only the data that is required for the action to the server and get back only what's required to update the view, getting rid of the postback and the UpdatePanels.
(You'll notice my use of the terms 'action' and 'view' - yes, I am an MVC fan. The situation you are in is typical of the mess that is easily got into using WebForms and the ASP.NET AJAX controls.)
I must be missing something. Why is your updatepanel is reloading the entire page. The point of an updatepanel is to refresh only what is in that panel, isn't it? Thanks for the explanation. I guess we're talking about reposting the page and not redrawing the panel as I thought.
Try turning off ViewState, especially for grids.
What kind of control is most common on your page? Try replacing those with your own lightweight UserControl or Server Control that does not use ViewState or ControlState
For all Interested I want to add a solution on how to get rid of the Viewstate data on clientside. It does give the server an extra load but if you are in the same situation as me and have a lot of server power and need to take the load of the clientside this is nice.
Let all your pages Derive from BasePage.cs looking like this
public class BasePage : System.Web.UI.Page
{
protected override void SavePageStateToPersistenceMedium(object viewState)
{
string vsKey = String.Format("VIEWSTATE_{0}_{1}_{2}", base.Session.SessionID, Request.RawUrl, DateTime.Now);
Session.Add(vsKey, viewState);
ClientScript.RegisterHiddenField("__VIEWSTATE_KEY", vsKey);
}
protected override object LoadPageStateFromPersistenceMedium()
{
string vsKey = Request.Form["__VIEWSTATE_KEY"];
return Session[vsKey];
}
}
Now you have a key to the viewstate data session instead of the viewstate in your code...
Works like a charm for me on a website with 1000-1200 daily visitors as well.
I have a page with a number of ListViews that I want users to be able to sort and page through. Rather than postback and rebind the entire page each time, I would like to do it via jQuery/AJAX selectively for the control in question. I am comfortable making the client-side call to a WebMethod in my page - my question is how do I get the returned data back into the ListView via jQuery?
(Note: I don't want to use an UpdatePanel!)
I'm not sure if it'll actually be achievable to update a ListView without a postback, just because of the underlying data model of the ListView control.
You're best option to having a complete AJAX solution would be to use a JavaScript templating engine. I've done a demo on my blog using jTemplates and the MS AJAX Library v4 preview - http://www.aaron-powell.com/blog.aspx?id=1209
But despite common belief you can use an UpdatePanel and have it efficient, I also looked at that here: http://www.aaron-powell.com/blog.aspx?id=1195. The biggest thing to keep in mind when using UpdatePanels is ViewState. If you don't need ViewState saved on a control make sure it's turned off. You can really reduce your post-load by doing that. Also removing whitespace will help.
I am looking for an example of using ASP.net AJAX to show a 'live' filtering of a repeater control based on what is being typed into a textbox. I have seen stuff using the Web Client Software Factory but am more interested in something that doesn't require an additional library.
The asp.net ajax control toolkit has one here.
If you don't like that one, searching google for "Ajax Autocomplete" gives lots of decent looking results, unless I am mistaking what it is you want to do.
I think you're a little confused as to what AJAX entails. If you want the filtering to interface with the server control's datasource, then it would not by definition be AJAX.
Live filtering a databound control the way you want is ill-advised, I think. For each iteration you'd have to re-bind the control, which would create a tremendous amount of overhead.
You'll need to find a way to do this client-side, with javascript. It could simply hide items within the repeater-created markup as they are filtered out, although how exactly this would be accomplished depends entirely on what html you're generating with the repeater.