on postbacks- can they be avoided?
i've developed a few sites now using asp.net and want to start looking more closely at the finer points of implementation details.
one thing that has always stuck with me was asp.net's dependence on postbacks when changing state. this happens when sorting a datagrid, clicking on a button, etc.
the main problem i have with this is that a user refresh prompts for a retry/cancel when really the user might just want to refresh the data on the page. in my mind, the ideal case would be for asp.net to perform the action and then reload the page cleanly (after which the user can freely refresh with no prompt to resend the information.
in the old asp days, i would accomplish this by posting to some processing page which was pure script, perform whatever action (db insertion, etc), then redirect back. maybe stylistically this wasn't the best way to go about doing things, but it accomplished the primary goal of the site- clean navigation that was always updatable with a refresh.
asp.net has done wonders as far as what you can do. onevent handling, sortable datagrids, etc... all handled in one page is really nice. but now there is the non-refreshable page problem for me...
is there any way to get around this? should event handlers redirect while using the querystring? should session variables be used? i'm not sure if this is a problem for anyone else, but i'd love to hear various other people's takes on what the best practices are.
enlighten me and help me clean up my apps!
thanks in advance.
What are you doing, what is the application.
You can still use the form action and have a page just for scripts. You can do everything you did in asp classic in asp.net, and more. Infact you can still use the <% code block %> and all of the other stuff from classic, nothing is stopping you.
i'm not having a specific problem, although i will present one to you:
i have a database-bound webform with a simple sortable datagrid on it. when a user sorts by clicking on a header, the sort event handler is fired, a posback is done, and the net result is the grid is re-databound with the data sorted in the desired way.
the problem here though is that a user cannot refresh (by hitting 'f5' or 'ctrl-r') without being prompted to re-send this information (post again).
to me, this behavior is undesirable. i'd like the user to be able to refresh whenever he wants without having to re-send information. the only way i can think of doing this is to do so using response.redirect in the event handler.
how about i run two ideas i had by you:
1) use the querystring- while certainly not the most elegant, i could pass sorting information in the querystring (and in whatever format i choose, whether that be one 'sortcriteria' name-value pair or multiple). if this were the case, the onsort handler would call response.redirect to the same (current) page, but would also be responsible for setting the appropriate querystring values.
2) use session variables- i still don't know if it's considered 'bad practice' to use session variables, but instead of redirecting and using the querystring, the sort handler could set some session variables (ie Session["sorttype"] = "hitsdesc") which would need to be passed into the databind on page_load and handled appropriately.
i'm not trying to do things in a classic asp way. in fact, i LIKE the asp.net model much better. but there are a few minor details such as this that stick out. your feedback & thoughts are greatly appreciated. what do you think of this?
Use the query string. That is what I was going to suggest before I read your ideas. Response.redirect him to the new page with the query string, or use a cookie. I would not suggest using the session state because it can decrease performance, and the session state is buggy. But the one good thing about a query string is the next time a user visits the grid would be in its default mode.
I like the asp.net model, but I still do some things like classic. Like I do not always use a server side form because it can be less conveiniant, and I do not use the form validation controls, etc.
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)