I'm developing a custom URL Rewriter for a ASP.Net 3.5 project. This rewriter is not functionally different than most rewriters out there, the only difference being that the friendly URL collection is not loaded from a web.config file -- it's coming from a database instead. I made the naive assumption that it would be easy to develop a custom rewriter module from scratch, but now I know the mess I put myself in. I digress; let's go straight to the technical issues.
While testing the rewriter, I set up a friendly url that would take the user to a web form. Postbacks from this form should not alter the friendly address, as anyone would expect, so
http://my.web.site/app_root/FriendlyURL is always rewritten as http://my.web.site/app_root/not_friendly/form.aspx
Things are fine when the browser first loads the FriendlyURL. The page comes up and is completely functional. However, when the form is posted back to the server, the page simply reloads but, at server-side, IsPostBack is false. It's like F5 was hit, except that a HTTP POST had indeed occurred.
Unsurprisingly, when the interaction occurs through the "unfriendly" URL, the POST action triggers the postback as expected. This evidence suggests that HttpContext.RewritePath is somehow messing with the page lifecycle in a way that it loses sense of the postback operation. Any directions? Thanks.
Thanks to StackOverflow, another nearly-duplicate problem gave me hints about the core issue. In short,
Server-side components that set the PostBackUrl attribute mess up with path rewriting system during postbacks. Or the postback system is messed up during the path rewrite. (The causal relationship is unclear, but the effect is what I described in the question.)
Any asp:LinkButton, asp:Button or asp:ImageButton that sets PostBackUrl (either at form, master page, or user control levels) will cause web forms to include a __PREVIOUSPAGE hidden element whose contents are opaque, but it has some role during postbacks. This was my problem: there were several asp:LinkButtons that set the PostBackUrl attribute.
When the page (form + master page + user controls) is free of PostBackUrl'd elements, __PREVIOUSPAGE disappears and the postback mess up is gone. So after I reviewed each asp:LinkButton in the entire site, and transformed them into ordinary <a> elements, the problem was solved.
Related
Apologies if this is vague or too general, I know we are supposed to ask specific programming questions, but this is to try and understand how postbacks work in ASP.NET when something is rendered on page initially, and not touched on postback, yet still appears on screen after these postbacks.
Detail: I have an ASPX page - on initial page load it sets up all the labels and controls and a repeater with thumbnails in it.
I can follow the code through as it sets up all components, which will then be rendered.
On postback, if a value has been changes (status for example), the page makes updates to database, and then re initializes the screen (calls the init method with postback set to false), setting up everything again (I think the aim was to set up certain controls like radio buttons for the status), including the image repeater again (which I think is a waste of time).
I have tested skipping the code that sets up the image repeater etc. on a status update (postback), and the image repeater displays fine in the browser - however I am not sure why - ASP.NET is stateless, so on a postback, if the page does not render all the components on the page everytime how can they persist between postbacks?
I know there is a reason out there, just can't frame my question well enough in google to find it. Does the server send back and update which the browser merges with the existing displayed page? Leaving all unchanges components as is?
The reason I need to know this, is I have a screen with a lot of images on it, and I do not want to be setting them every time unless I have to.
This link - provided by Steve (thank you very much) - was what I was looking for goes into depth on ViewState - vaguely remember reading about that when I first stated doing .NET - have completely forgotten about it, but this explains it perfectly!
Understanding ASP.NET ViewState
https://msdn.microsoft.com/en-us/library/ms972976.aspx
Problem:
I am loading one of several user controls based on a selected tab within RadTabstrip Control which is on the parent page. I've captured the Selected Tab and assigned it to a Session variable within the OnTabClick event to use in each User Control to determine if that particular control needs to be rendered.
The reason for this is because each User Control queries a database to render different charts and I don't want unneccesary processing occuring on every post back to the server. I'd like to add that each User Control has several Labels in their Markup that only gets the Text values assigned during runtime based on the content retrieved from the database.
When I load the main page, the selected tab variable is checked by each User Control and everything works fine from that scope. (The first tab at index 0 has no Charts)
Problem is when I select a Tab which has a User Control, the appropriate code to acquire the data from the database and build the chart works fine but the TEXT value of the Label controls in the Markup don't show up on the Page, although the TEXT values are being set in the Code-Behind at the same time the data is being retreived.
If I perform a Post Back of the same page, the TEXT values of the Label controls appear.
I believe this is because the 1st stages of the Page Life Cycle which include the rendering of the Markup aren't firing on the initial loading of the User Control, but get fired on subsequent Reloads or Refreshes of the Page.
Is there a way to work around this? I am figuring a call to the Render event after hitting the database would work but I may be way off base on my thoughts.
Can anybody provide some advice or a potential solution???
Thanks
I was never able to resolve the late binding issue which prevented the text of the labels from appearing until after a manual refresh of my page so I approached the issue from a different angle. I still retained the logic that only allowed the data of each User Control to get populated if their corresponding Tabs were selected by the user, but I moved the in-line code which was embedded in my Markup to my Code-Behind file.
I was not 100% certain as to the order that the mark-up vs. the code-behind got processed, so I researched and found that anything done declaratively in the aspx page is processed first, and the objects are created before being accessed or updated in the code behind.
So with this information I totally separated the two and was able to get the Text to render on the labels without any issue.
I still would haved liked to have known the appropriate way to force a page to call the Render event to simulate or mimick a manual Postback after the initial Page_Load, but going with the flow of the Page Cycle is the much easier and probably a more preferable way to do things.
One way to approach your problem is to consider use of the "Update Panel". It will allow you to render the entire page and then on an event only refresh the area of the update panel.
Generally I would love this feature for performance reasons but there is a catch. Some browsers (e.g. versions of Safari and Opera) do not render these correctly. Is your application a web application intended for general use by consumers? If so you may need to consider a full page refresh on the same page and pass the user data (unless Opera / other browsers have fixed this shortcoming - I have not tested in in 4 months).
I have a simple three page asp.net webforms site and having an issue with the back browser button that throws the popup "...Firefox must send any information that will repeat any action.." when hitting back on the step3.aspx.
The flow is: user lands on step1.aspx, session starts, and a user quotes on a product and gets redirected to step2.aspx. On step2.aspx, you confirm the purchase by clicking an asp:Button. The OnClick event handler, btnPurchase_Click, handles the logic for purchase and redirects, Response.Redirect("step3.aspx"), to step3.aspx. Step3.aspx simply displays the confirmation page (receipt details). The session is destroyed on step3 and when the user hits the back browser button, they are prompted with the resubmit post popup. Ideally, I want the user to hit step1 on hitting back without the resubmit prompt. Each page is set to no-cache and redirects to step1 if session is invalid.
Does anyone have a suggestion for a better flow?
This site will eventually be migrated to asp.net mvc/ajax which will most likely make the PRG workflow easier to implement but for now, looking for a relatively simple way.
A simple solution is to never allow a page to render on postback, but instead accept/store whatever information it was posted, and then redirect to the next page (or itself).
That way if a user hits the back button, it is going back to a GET, not a POST, and avoids the popup.
I give this question a try. The flow you mention will obstruct the pages normal function, which you of course already have in mind. Though, i would say it can be dangerous (against the function you expect) and contraproductive. Based on what I can see from your question, I would definitively remove Page2 and Page3 and keep all logic in same and single page.
I would also be happy to hear what you are trying to avoid, with this? Is it double posts? Like a double-post of a content in a shopping cart? Partial / uncomplete inserts of data input? With the described way to affect back-buttons, you may come around one problem but rise another. A big range of browsers that can act completely different on such work-arounds.
I see two good options,
UserControl,
Create three UserControls which every each of them have each page specific logic. You can programmatically load them into the page. I.e. on bnButton_Click Event. Usercontrols are loaded with LoadControl("PathToAscxFileOnDisk.ascx").
Panels,
I would also think about three <asp:PlaceHolder></asp:PlaceHolder> or perhaps better <asp:Panel></asp:Panel> to put all logic into.
In this case you are completely free from the postback issues and can focus on moving your functions into business logic and have use the Code-File to control the flow on show/hide and populate the controls in/out from the panels/usercontrols. You can probably also control the postback / click-URL & push-enter-key.
And you mentioned Ajax,
Ajax is absolutely there to make your page stateless (which means you can work without cache, sessions, viewstate and so on. Though, the problem lies in the users possibility to navigate between pages. I would think even Ajax is of less help, while you keep the three-pages-solution.
I would personally say it is a simple task to move the aspx files into each ascx and create a aspx as a master-container. With that option you even avoid duplicate namings (like if you copy / paste the code into panels) and trouble with Page_Load flow/logic.
If I understand correctly you're not yet using the PRG.
On step 2, temporarily store the information and redirect to show it. How you do so depends a lot on your application: session, database, cookies, etc are all options with different caracteristics.
Then redirect to show that information.
Same goes on step 3.
If you hit back on step 3, you'll go to step 2. But given you're going back to a GET request, there won't be a warning. Like you said, your application destroys the session data on 3, so according to what you said the user would go to step3.
Maybe I'm missing something on what you said.
This is probably a simple question for every WebForms developer but I am knew to this scene. I have a page that has an "ADD" button on it that results in a jquery popup where the user can submit a form that will add an entry to the repeater on the page. My problem is that after the user adds an item, if they then hit the refresh button the item will get added again. I can't stop this with the page.ispostback because that would block the original add. What can I do here?
that's a common problem. Here's explanation and solution of the problem.
When a web form is submitted to a server through an HTTP POST request, a web user that attempts to refresh the server response in certain user agents can cause the contents of the original HTTP POST request to be resubmitted, possibly causing undesired results, such as a duplicate web purchase.
To avoid this problem, many web developers use the PRG(Post/Redirect/Get) pattern.
copied from wiki (LINK)
simplest solution can be Response.Redirect to the same page (i.e. if you page is named default.aspx write Response.Redirect("default.aspx")). if you do this browser refresh button will just load the page as if you have typed in address bar URL and navigated to it.
here's SO question How to stop unwanted postback that might be useful as well.
If there is an option to delete an item on the page (is there?), do you really have to be concerned with that happening? May want to think about that. Just a thought.
I have a website where there is a lengthy list of items to display so I am using Pagination to make the load on server easier.
However, I am doing the pagination via Ajax so when the user clicks on Next Page or Previous Page linkbutton, the data repeater is refreshed with ajax.
This was working fine until, people started to click on the item and then click back, it takes them to the first page.
suppose you scan about 10 pages, by clicking on the "Next Page" button. The data changes, but the URL in the browser doesnt. And you think you found what you want so you click on it, the browser loads different page, and when you click back, the browser takes you to previous page but since the url did not change, you are back to page 1.
Currently, I have removed ajax so the url changes everytime, but I have seen several website re-write the url in browser when ajax even happens, and I was wondering if I could do the same.
Google search for url re-write digs up only seo routing stuff, nothing on what I actually want (i am sure i am not using the right words)
I was interested to know this problem, any clues or leads on this one?
thanks!
ps: several questions here were kind of close, but was either too complicated or too deviated. sorry if its a duplicate.
The only part of an URL that you can change in js, client-side, without forcing browser to reload whole page is an anchor part (http://domain/page#anchor - the part after # sign). This part is used by many js application (e.g. Google Picassa), also by silverlight to provide browser history support. You'd have to set an anchor part when navigating to another page of your data. When the page is loaded, just check the anchor part and load appropriate page. Also, you'd have to periodically check for changes - this will happen when user uses back/forward feature in his/her browser. (There could be an event that is fired when that happens, I just haven't found it)