suppose i have many heavy control is on the page. as for example i have three gridview populated on the page and one gridview & button is inside the updatepanel. from this scenario we can understand that there will be huge viewstate on the page. so i want to know that if i click on button inside the updatepanel then all the viewstate will be submitted to server during partial postback or not. if huge viewstate submit to server and comes back to client then what is the advantage of partial postback because response time will be slower. so tell me how could i tune up the code that only required things will only submit to server. discuss the partial postback concept in detail as a result we can take right action to have good performance. thanks.
+1 to geek!
If you are concerned about the performance of your page(s), I would also recommend using ListView instead of GridView:
https://web.archive.org/web/20211020153238/https://www.4guysfromrolla.com/articles/122607-1.aspx
http://weblogs.asp.net/scottgu/archive/2007/08/10/the-asp-listview-control-part-1-building-a-product-listing-page-with-clean-css-ui.aspx
http://basgun.wordpress.com/2007/12/27/listview-control-in-aspnet-35-1/
http://basgun.wordpress.com/2007/12/28/listview-control-in-aspnet-35-2/
http://basgun.wordpress.com/2007/12/29/listview-control-in-aspnet-35-3/
http://basgun.wordpress.com/2007/12/30/listview-control-in-aspnet-35-4/
You can also visit Matt Berseth's blog to see how ListView can get very handy (and neat) for different types of development scenarios:
http://mattberseth.com/blog/listview/
it's important to keep in mind that an UpdatePanel's partial postback invokes a full page life-cycle on every single async request.
Please check out following links for pros and cons of the update panel.
Why ASP.NET AJAX UpdatePanels are dangerous
Why you should not place your whole site in an UpdatePanel
Are you making these 3 common ASP.NET AJAX mistakes?
so i want to know that if i click on button inside the updatepanel then all the viewstate will be submitted to server during partial postback or not
Yes, it will. The entire page's view state is transmitted (in its entirety) to the server on partial page postback, and the new view state is sent back (in its entirety) from the server back to the client on response.
I'd suggest you use a tool like Fiddler to examine the HTTP traffic between the browser and your server when making a partial page postback. This article provides an overview of using Fiddler - Troubleshooting Website Problems by Examining the HTTP Traffic.
In short, the UpdatePanel is meant as a quick and dirty way to get partial page postbacks without having to worry about client-side script or writing logic on the server to specifically handle a partial page postback. Such simplicity comes at a cost, as you've discovered. :-)
For more control over the content that is sent to and from the server on a partial page postback you need to write client-side script and create server-side methods or services to handle the Ajax requests. These articles offer various techniques for providing such functionality:
Accessing JSON Data From an ASP.NET Page Using jQuery
Using Ajax Web Services, Script References, and jQuery
Using WCF Services with jQuery and the ASP.NET Ajax Library
Related
I would like to take one decision based on the question described. I had already used PageMethods in clientside code. If it triggers postback then I wanted to replace it with ajax call from client side. Can anybody clarify it?
A web method of the given page when called by a ajax call client side does NOT cause a post-back. But, keep in mind that such web methods can't referance any control on the page, nor can you use ViewState. You can use session() in a web method.
Often, in some cases, you can then adopt a update panel, and put the controls in that update panel, and thus when you click a button, or any event code from a control?
Then you don't get nor see a full page post-back. So often, a update paneal is a great way to prevent and not have full page post back. But, do keep in mind that a update panel DOES cause a partial page post-back, and even your page load event fires again.
But, a web method? No page post back occures. You often require this since a jQuery.UI pop dialog can disply things, but if that dialog needs server side code, then you can't have a post-back (since then the dialog will collapse, since you getting a new fresh re-rendered page. And even using a up-date panel will also collapse a dialog.
however, if you don't have some pop dialog showing? Then it MUCH less work and effort to just use a update panel, and not bother with all the work to wire up a ajax call to a web method.
So, in most cases I don't make the time + effort to build a ajax call.
So, look into a update panel first - often less work.
But, if you just need some value from the server, don't want a post-back, and don't want (or can't use a update-panel), then a web method is great choice. (since no post-back occurs). The big down side of a web method is no use of controls or anything from the web page can be used in that ajax call to the web method (so, you have to have the data you need client side, or pass some value(s) to the server side web method.
A pagemethod also does not cause a post-back.
I have a listview with 250 rows and 4 columns in my ASP.Net 4.0/C# application. The Rendered page size (from Trace) is 650,000 Bytes. The entire listview is in an update panel.
The listview facilitates view/add/edit/delete operations on the listview records.
Every POSTBACK action (i.e. edit click, delete click) causes a POSTBACK request of size 112,000 Bytes and an AJAX Response of ~650,000 Bytes.
The listview gets the data from a declarative data source (SQLDataSource) on the page. And the listview is bound on each round trip.
I want to reduce the data going back and forth in every call because on a slow connection, these AJAX calls take 2-3 minutes to complete.
What I have tried -
Removed the update panel over the entire listview and added an update panel over each:
ItemTemplate contents
AlternateItem Template contents
Edit Template contents
Insert Template contents
I was hoping that with the template in each row, it would reduce the size of the AJAX response since only the HTML for the update panel would come back. Unfortunately, it does not seem to work that way.
Any inputs on how the problem in my case can be solved?
Thanks in advance for looking this up.
The problem with an UpdatePanel is that you are not using real AJAX. Instead ASP.NET uses some really clever hacks to create the illusion of a partial page update. On the background, your whole page life cycle is executed. This also means that your complete ViewState is send back and forth.
If you want a faster experience, you should not use UpdatePanels. Instead, use plain HTML controls (preferably not even server controls) and use JavaScript and a server side webservice (such as WebAPI or a WCF service) to respond to the client side requests.
Those requests and response will only contain some JSON data and no markup. Your data can be kept to a minimum. If for example, a user removes a row, you only have to send the Id of the row to your service and it will return success or failure. The client will use JavaScript and maybe something like KnockoutJS to render the result. This will give you minimal overhead and a better performance.
The best possible way to do this is to not use the ASP.NET user controls and instead do this cleanly using JavaScript, JSON, HTML and a server side web service/http handler
That way you don't have to send large HTML responses from the server to client. You can also control when need to refresh and rebind your data.
I bet the whole size issue has to do ViewState. The reason being that on every postback, even if it's an AJAX postback the ViewState travels with it on every request. The only thing you can do, without making any changes, is to enable compression on the IIS side. This, at least, will send the response compressed and the browser will take care of decompressing it.
The best approach is not to use UpdatePanel and ScriptManagers at all and instead make AJAX requests using jQuery (or whatever framework you prefer) by invoking a WCF Web service. This will not trigger the full page lifecycle and will not send the ViewState on every request.
I have an ASP.Net application that has a UserControl that needs to be rendered on an ASPX page (as normal), but also via Ajax using a Handler.
One solution to this is to get the UserControl to simply build up a HTML string, rather than rendering controls as it would normally.
That way, the ASPX page can simply populate a Literal control with the output, while the Handler can write the output to the Response object for Ajax to pick up.
Is this the ideal solution? are there any drawbacks of this approach?
If you do that, you have to recreate the user control every time from the client-side when a postback to the server happens. However, performance wise, that may be better. However, I don't think the UC can then participate with viewstate and the ASP.NET object model as a typical user control would. You would have to account that all actions within the UC are handled appropriately, to react to the web.
If you have a large amount of content to render, the UC approach is just fine. We're talking rendering markup and injecting it into the UI, and so that does pan out and can make it easier. If it's not that much markup, any alternative would do.
If all you need to do is push data to the client, an alternative could be that you push JSON to the client through a web service, and build the UI on the client. That's efficient too.
HTH.
There are a number of JS templating tools available now that will solve this problem. Take a look at mustache js, which can allow the same template to be rendered in client side JS and in C#.Net.
You can then create on template file and either render the HTML in JS via Ajax or render in .Net and simply output during page load.
Ok, so the problem is as follows: I'm using jQuery's AJAX in order to make behind the scene calls within the page (on events such as voting an item) and changing the content in the appropriate element. The problem occurs when I mix AJAX with ASP.net's AJAX, more precisely when I try to do a postback AFTER I've used jQuery on the page to perform an action. The page's viewstate is changed and validation fails (which would seem somewhat normal as a matter of fact).
My question is: can I disable the validation somehow so that I can perform postbacks combined with the chaged page viewstate? So far searching on how to disable it yielded no results.
A more practical example is on a comments page where I allow voting the comments and posting new comments as well. So should a user vote a comment and THEN post his own, the page's contents is changed, and thus validation fails. Also, I've tried placing the comment form within an update panel as to prevent the entire page from posting, but it still fails.
Of course I could use an alternate route and have a different page for handling the event and just call that via jQuery's AJAX, but I was wondering if I could do this by combining ASP.net and jQuery.
Thanks in advance.
If you want to disable viewstate verification, you can set it at the page or config level by using Page.EnableViewStateMac = false.
http://msdn.microsoft.com/en-us/library/system.web.ui.page.enableviewstatemac.aspx
It's not necessarily a good idea though because the validation functionality is there to protect from viewstate tampering, which you'll be turning off...
If you're running into issues with invalid viewstate because of jQuery ajax calls, one option is to consider using the Ajax controls, such as the UpdatePanel. You can wrap certain controls and mark the UpdatePanel as conditional to ensure a small round trip. This will not interfere with viewstate and allow you to continue to use viewstate validation and ajax at the same time.
There may be ways to use jQuery ajax calls and not interfere with viewstate validation. Others may be able to highlight this approach.
For example,
If I have a textbox with runat=server on a page, The value will be posted back to the server so I can access the properties in the code-behind.
However, under the following situations, does it still hold true?
A textbox with runat=server but does not appear in the function that is post back to. For example, a button is also on the page, when clicked a post back occurs and within the method that is raised, this textbox was not used.
Within a MasterPage, will a textbox residing on the Masterpage itself be posted back?
Because just thinking, isn't this mechanism bloated in nature?
If all input controls and its value are posted back on every single button click (even when the input control is not needed), doesn't this deteriorate performance?
Having just one Form Tag on the page really restricts us to using this mechanism?
Truly Understanding ViewState is a must read article on the subject of ASP.NET ViewState
There are several options to cut down on the bloat (and yes, there's a lot of it when dealing with lots of controls):
Use AJAX to post only the items required - although be careful to allow clients that don't have JavaScript enabled to still use the page/ site.
The MVC framework allows multiple form tags to be used so you can group sections if needs be.
Set the EnableViewState to false on pages/ controls.
Break up your pages into smaller ones.
Additionally, check out this brilliant graphical representation of the Page Life Cycle in ASP.NET.
Every input on the page is posted back fully unless you use ajax, because of the single form tag. Welcome to asp.net...
As long as the method that you're hitting on the server-side is a non-static member of the page's class, it'll have access to the textbox and all other controls on the page.
And yes, all controls rendered to the browser (whether in the MasterPage, user control, etc.) will be available on post-back.
You may want to look into Understanding ASP.NET View State.
There surely are performance hits with this architecture, but (depending on complexity of the page) it's usually not an issue from the server load perspective, because hardware upgrades are typically cheaper than additional programming hours spend on optimizing application performance.
With that said, (and as others have pointed out) look into using AJAX if you want to avoid whole page-level postbacks to the server.
Yes, it's all posted back, and yes it can cause bloat. I'm sure if you search for ViewState you will find plenty of people ranting about it and how to minimise it :)
Yes your text box will be available in both cases, yes it is bloated. This is where AJAX comes into play. Using AJAX you can send just the data you need.
If you want to send a minimal ammount of data, you could use a Page Method (static method on page decorated so the script manager builds javascript to call it or you could call it using jquery or other methods), or a script enabled web service works nice as well.
You also have viewstate which can get very large. ASP.Net MVC is a new paradigm instead of using WebForms which doesn't have view state, or post backs. It embraces HTTP instead of hidding it giving developers more control.
The textbox data would be posted back as noted. In addition to using Ajax, disabling view state greatly imporoves your page's performance though even then data in properties critical to the functioning of controls (Control state) would still be posted back.
If you didn't have postback for every control on the form, you wouldn't be able to access it in code-behind. I.e. if in your button press you wanted to modify the property of the text control you couldn't do that because ASP.Net would know nothing about the text control.
Since the communication between the server and the client is stateless and every time a page is server the server forgets all about it Postbacks are important if you want to work with the same page again. No matter what programming language you use, this or similar mechanism exists for processing server side code.
If you wish to minimize postback (viewstate size), do this.
Set enableviewstate=false on all controls that you don't want posted back.
Use AJAX and web services wherever possible (and don't use UpdatePanel).
Use HTML control as much as possible instead of ASP.Net controls.
Hmm.. There are some excellent suggestion in other answers and good links too.
You've pretty much hit the nail on the head with vanilla ASP.NET - it's not very good! In both the instances you describe the answer is yes - the textbox will be sent with the form.
The whole postback/ViewState problem is a bit of a pain, one of the first things any competent ASP.NET developer learns to do is avoid them!