Partial postbacks don’t work how I expect
-
Why and what can I do about it? I have a calendar control that is contained within an update panel. It all works nice and smoothly and I am happy with it. Demonstrating the app to colleagues and the talk came about as to why I didn’t create a client side calendar control with javascript rather than use the standard asp one. My argument was that the control does what its supposed to and works. He said that if we rolled this out to a customer the amount of data being posted back would mean a slowing down of the app(some of our customers only access is through dial up.) ah ha I said that should not be a problem cos its in an update panel so the whole page is not being posted back only the calendar is! He then went on to disabuse me of the notion that even thought that is what is supposed to happen asp.net sends back viewstate and rendering info for the whole page!!? From what I have read around the net he appears to be correct as well, its something to do with the page renderer requiring hash codes or something for all the controls on the page. Now this seems poor to me, the only advantage to using this now is cosmetic and I can do without that if its gonna slow my app down. Has anyone had any experience with this? Am I better to code up a javascript calendar control, and use that or is the pay off between amount of code downloaded for that compared to the data posted back for the Ajax update panel mean that it’s a much of a muchness? I am pretty new to asp and web dev so if anyone can offer a differing method to partially update the page that would also be appreciated…any links to tutorials or lessons or what not, you know the kinda thing :D The performance hit seems to be the biggest deciding factor in this company as to what tech to use in a certain situation. Cheers Ian
-
Why and what can I do about it? I have a calendar control that is contained within an update panel. It all works nice and smoothly and I am happy with it. Demonstrating the app to colleagues and the talk came about as to why I didn’t create a client side calendar control with javascript rather than use the standard asp one. My argument was that the control does what its supposed to and works. He said that if we rolled this out to a customer the amount of data being posted back would mean a slowing down of the app(some of our customers only access is through dial up.) ah ha I said that should not be a problem cos its in an update panel so the whole page is not being posted back only the calendar is! He then went on to disabuse me of the notion that even thought that is what is supposed to happen asp.net sends back viewstate and rendering info for the whole page!!? From what I have read around the net he appears to be correct as well, its something to do with the page renderer requiring hash codes or something for all the controls on the page. Now this seems poor to me, the only advantage to using this now is cosmetic and I can do without that if its gonna slow my app down. Has anyone had any experience with this? Am I better to code up a javascript calendar control, and use that or is the pay off between amount of code downloaded for that compared to the data posted back for the Ajax update panel mean that it’s a much of a muchness? I am pretty new to asp and web dev so if anyone can offer a differing method to partially update the page that would also be appreciated…any links to tutorials or lessons or what not, you know the kinda thing :D The performance hit seems to be the biggest deciding factor in this company as to what tech to use in a certain situation. Cheers Ian
unfortunately I've had experience with unrealistic expectations of what Ajax can do. How long would it take to write a Jarascript only version? what about the size of the initial down load with all the Javascript? what about support for different browsers? you can Still use the calendar control and use Ajax without the update panel by handling the Java script events.
only two letters away from being an asset
-
unfortunately I've had experience with unrealistic expectations of what Ajax can do. How long would it take to write a Jarascript only version? what about the size of the initial down load with all the Javascript? what about support for different browsers? you can Still use the calendar control and use Ajax without the update panel by handling the Java script events.
only two letters away from being an asset
Mark Nischalke wrote:
what about the size of the initial down load with all the Javascript?
That's the important thing I think. Whether the postback of the viewstate will be cumulatively less than the initial download of a dhtml/javascript calendar control. Cheers Ian