I have a repeater that houses a gridview. That gridview needs to be editable, and to make for a more fluid experience, I have the gridview wrapped with an update panel. There are n number of update panels on the page based on this. Everything is working perfectly fine, but I'm asking because I'm afraid of problems that may arise, such as postback size. Is this the best way to do this? Are there any pitfalls I'm not seeing?
You have an eligible concern.
First thing to know if that UpdatePanel post the whole page to the server, always, even including whole ViewState content. Nothing you can do about it, just make sure you acknowledge that. So if your page is very large and you notice significant lags in how the app works, you might want to consider a different approach, perhaps with manual async calls, or something like that.
Second thing immediately follows - whenever an UpdatePanel does a postback, server does the full page life cycle, and then just a part inside the UpdatePanel is updated on the page. Again, nothing you can or should do, this is just how UpdatePanel works. People are sometimes surprised by that fact while debugging, so it was worth mentioning.
Third thing is specific for your case, cause you have multiple UpdatePanels on the page. By default if one of them does a postback, all other panels do a postback as well, and consequently they all are updated. Maybe this is a desired behavior, maybe not. If not, you can set UpdateMode property of each UpdatePanel to Conditional, and they will be update only GridView inside triggers an update. More on this here.
These and much more other details on UpdatePanels, can be found in this article.
Related
Apologies for such a broad, sweeping question, but I can't really give specific code examples because as far as I can tell from research this problem is unique to the particular page I'm working on and if I knew what to do to replicate it then I'd most likely be able to fix it.
I have an asp.net vb (v3.5 using the ajaxcontroltoolkit v4) page essentially binding some straight forward SQL database data to a gridview.
The gridview's in an update panel and whenever I do anything that causes a postback inside the update panel, everything outside the update panel vanishes. The update panel IS updating correclty.
There's no conditional updating, just an 'out of the box' update panel.
All other ajax functionality is working correctly, such as filtered textbox extenders and validation with callout extenders, so I don't think it's a basic script reference error.
I'm making use of javascript and jquery to modify controls on the fly that are within the updatepanel.
It was a standalone page for development but for testing this problem I put it into a contentplaceholder on a masterpage. Now on updating, everything else in the contentplaceholder disappears, leaving the masterpages header etc present.
If you haven't come across this particular problem before, can you think of how I could go about debugging it?
If you have any ideas at all, it might be enough to set me down the right path.
Many thanks.
Thanks for taking the time to make suggestions Mt. Schneiders.
In the end...haha wow, embarrassing... I've been doing this for the best part of 6 years now and I was closing my updatepanel before closing a div that started above the panel.
Simple fix. Yay! Thanks again.
I have an asp 3.5 site that communicates with an Oacle DB. I put a CoolGridView on it that binds some object and when users click a CheckBox I fill in a textbox on that row with some data.
However, the scrollbar behaves weird, sometimes it jumps to the top sometimes to the bottom whenever I select anything and creates a postback.
Is there an easy way to avoid this? Some hidden property I never noticed?
And yes, I have the maintainScrollPositionOnPostBack set, I read somewhere that I need to have my CoolGridView in an UpdatePanel. Well I don't, never used them, seem that I need to rewrite the whole Grid if I change this?
But maybe I have to?
Regards
I think I got it working, wrapping only the GridView in an updatepanel and throwing in a ScriptManager sem to have solved it..
I have a repeater control that displays a playlist for my users, this control can sometimes hold say 1000 or more songs. This is a great feature, I was previously using jQuery to do client side sorting, but that has limitations. So I implemented server side sorting which works great, the only issue i am seeing is that when playlist are this long it takes a second or 2 before the postback and sorting is actually started.
I have watched the actions in firebug and done some research and understand that the databound values are not preserved, which makes sence. My question is, When watching in Firebug, it looks like the repeater control removes all the items in the collection before it starts the postback? is this true have others experienced this?
The repeater control ceases to exist entirely between postbacks. The repeater control is called into existance when you make a page request. It is populated, etc. then rendered to the browser. Once done, ASP.NET will delete all the objects on the page (or rather the garbage collector will get them when required. Either way, you can't get them any more).
When the postback happens it has to re-create the entire repeater all over again. There are some mechanisms, such as viewstate, that try to make this as seamless as possible (i.e. recreating controls just as you left them in the previous request) but they sometimes don't work the way you might expect.
In asp.net is it a requirement to rebuild the whole page during every callback? For example my web page is split into three distinct areas and I have an update panel for each area. Lets say I want to update the third area, do I have to bother with any processing of the other two areas?
For example lets say there is a grid view in area two. The update panel in area three callbacks to update its content. Do I have to rebind the grid in area two?
Thanks,
AJ
Yes, this is how ASp.NET is done. If you use an updatePanel / AJAX partial update, you may get away building only part of the page. But then, your viewstate may be a problem.
What you see is basically one of the disadvantages of the ASP.NET model.
By default, "UpdateMode" is set to "Always" for UpdatePanels which means they update whenever anything "happens" on the page.
Try setting "UpdateMode" to "Conditional" for all your three UpdatePanels and see if that helps. (FWIW this is standard practice for me as part of writing the UpdatePanel definition. If you need to update an UpdatePanel when something happens on a different part of the page, you can use Triggers or update it with .Update() in code behind)
bgs264
Edit
I think I misunderstood your question originally; my suggestion above may improve page rendering times as partial postbacks result in less code being sent back and forth between client and server.
But yes as per other answer, all the controls have to go through their lifecycle (Init, Load, Render) on every page load / postback.
I have a web form that has multiple ListBoxes, TextBoxes, DropDowns. If I put one UpdatePanel around the whole page, I noticed the page is slower. Is this because, every control is being updated? If I put different UpdatePanels around each control, I noticed the page has a better response. Is it right to assume that this is because I have more control of which parts of the page are updated based on selections from ListBoxes and DropDowns for example?
Thanks,
X
each update panel generates a round-trip to the server (i assume you're using a timer or something to cause this)
the general rule would be to group controls in an update panel that must change together, otherwise separate update panels makes more sense
I use update panels with a set of related functions in mind. I find that for my apps when there are related pieces of content on a page, such as a search tool, it is best to be placed in its own update panel. Be careful putting too many update panels however on your page as the client will have to download more code to make it run.
A rule that I use is to set the update mode of all panels to only fire when children are changed, and in some cases it's best to do it programmatically in your code behind. This is best in cases where you have a section of items in another update panel but both don't need to be updated or the parent one only needs to be updated on occasion.
By triggering the panels in your code you will create a little more work for yourself but in the end you will also have a lot more control over the user experience and this may help you also send fewer bits down the pipe.
Andrew