I want to create an error handler for a mvc project, but the error message should be displayed in a popup. I tried to override onException event of the controller, but I don't know how to get back to the initial page and show the popup. I don't want to be redirected to an error page. Any advices?
The only way to do this is to do an AJAX form submission. If the save fails, show a popup. If the save succeeds redirect the user to a new page. That's the only way to keep the user on the page. (Well the only non-clunky way.)
As mentioned in the top-level comment by zvolkov, this is very desktop-y. There shouldn't be a 100% correlation to how a desktop program works vs. how a web program works. While there are parallels, it's OK to deviate.
The hardcore standards folks will tell you to not rely 100% on an AJAX submit, since it isn't 100% browser compatible and can break on some smartphones, depending on what you're doing. You form should be able to gracefully fall back to a standard HTTP-POST action.
Related
I have a contact addition form that can be navigated to from multiple screens in our application.
Once the form is submitted, I then take the user to a screen to view the contact that was added.
When the user then makes use of the back button it should take them back to the screen that they originated from.
This might be the Android back button or one that calls the RouterExtensions back function.
I have made use of the navigate extra replaceUrl when navigating away from the form to the view page.
I have also tried using the skipLocationChange extra when navigating to the form but this creates more issues.
I have created a simple playground page flow that creates not quite the same issue but does throw an error that I don't know what to do with either:
https://play.nativescript.org/?template=play-ng&id=BfVcGZ&v=2
In our app, by making use of the replaceUrl extra, the back button does take the user to the correct page.
However, there is a brief moment where they see the form again. This isn't an ideal user experience.
In the linked Playground I do get an error:
Cannot reattach ActivatedRouteSnapshot created from a different route.
This seems to tell me that replaceUrl is indeed removing the page from the route table.
However, the page isn't destroyed yet and so the app is trying to show a page that it shouldn't.
replaceUrl is not yet supported by Page Router Outlet, there is an open feature request, you might want to register your vote on the feature and follow up there for further updates.
So a user fills out a form then decides to click on a unrelated link that happens to be on the page say to a disclaimer page. Then using internal site navigation (not the browser back button) comes back to the form he was on. The link back is an ActionLink.
What is the best way to keep his data on the form. I figure I'll have to serialize the data and save it. I can do a ajax call before going to the other page. I'm looking for the sexy solution. Something that will handle it on a global scale.
Is this even a standard practice?
HTTP is Stateless. You are trying to bring some Stateful nature it !
If you really want to keep the data, You can keep in the Session variable and access it there. You need to override the click event and (in javascript) send the form data to an action via jQuery ajax post where you store it into Session. You can access it later when you come back to this page.
Do you really want to do that ? I think 80 % people knows that once they click on another link, the data will go away. You could probably show some alert message to ask "Are you sure to leave this page" like stackoverflow does.
I've got a communication between client and server. The process is simple:
I'm making an AJAX POST request to a controller which generates a pdf in the file system
On success of the above request a form GET request is made to get the pdf back and the standard browser "save or open" dialog box opens up
The reason I'm having a two step process is because I need to have a progress bar while the pdf is being generated.
The reason of the second request being a form submit rather than part of the AJAX request is because I can't get the standard browser "save or open" dialog box.
The problem with this approach is that IE7 & IE8 pop up a their annoying notification bar notifying the user that the it is dangerous to download the content and I don't want that.
So:
I need the progress bar.
If I go for an AJAX request only I need a way to pop up the "save or open" dialog box.
If I go for the a form GET submit I need a way of knowing when the file has been generated in order to stop the progress bar, something like a shared flag between server and client.
Any help appreciated.
One possible (a little of an anti pattern) workaround is this, but it's not a great design probably
However I've seen this (and admit I did this) before, and except some guilt, it did the trick
user clicks a link that goes to the servlet that generates the PDF and will just wait (timeout settings should be applied) until it's ready... (Content-Disposition header etc...) just like a regular download
The servlet will report progress on a shared session variable while generating the PDF
an AJAX call to the server will read from the session variable the progress and show to the user
when the PDF is done, the browser will just download it (request timeout risk perhaps)
The main issue here is using the request thread as a worker thread and blocking it, which may give this answer a couple of downvotes...
I'm not that familiar with Message Driven Beans but this is another, probably better solution.
If you go to http://jsbin.com/ibozun/2, hit "Add Item," and then hit "Save," you will see that a second dialog is opened on top of the first one. The form in the dialog is posting to itself (no action defined) - this is by design. Because the dialog has duplicated itself, now you have to hit "Cancel" 2 times to get it to close.
The use-case for this setup is a MS MVC3 page with unobtrusive JQuery validation on it. The default scripts (in other words, I have no custom validators - the scripts are straight from MS) cause an ajax call to the server, and JQM treats that the same as a self-posting form - so you wind up with a duplicate dialog if validation fails.
A similar thing happens if the second page as a page, rather than a dialog - the form posting to itself results in a second history entry in the browser, so to get back to page 1, you have to hit back 2 times.
I believed this be a bug in JQM, but after submitting a bug on GitHub, I was told that this is the expected behavior. So, assuming this behavior that will not be changing in the framework, how do I prevent this from happening for my instance (preferring NOT to edit the framework JS)? Do I have to write my own ajax calls for validation so that I can prevent JQM from knowing that anything has happened? That seems unfortunate...
One idea I had was to detect that the nextPage and current page are the same on "pageHide", and manipulate the dialog/history myself, but have had no luck.
Thanks in advance!
First, there is no dialog duplication in the example. Second, my response and an explanation as to why solving the history issues with posting back to the same page for users of the library is hard can be found here. This example is particularly thorny because it's also in a dialog which we don't support linking to, so disabling ajax for the form (ie forcing it to reload), which would work if it were embedded in a page, won't serve.
The quick solution here is to switch the dialog to a page and add the data-ajax=false data attribute to the form. Mind you this causes a page flash/reload and requires that the form document be fully formed with a head including javascript,css, etc.
I am a beginner using ajax and I always thought that it is completely asynchronous. But I discovered that a call can be interrupted by a page reload or a page change (like clicking on a hyperlink). I was under the impression that when an ajax call is started, it is carried out no matter what the browser does afterwards. Is that wrong?
Now to the specific problem I am having: think of an online test where users answer questions (by typing into textboxes). When a textbox loses focus, an ajax call is triggered which persists the value of the textbox to a DB. That works well when changing between textboxes. However, I also have a submit button which triggeres a post action to another page (it is the submit button). When I enter something into a textbox and click on the button afterwards, the call is not carried out. Moreover, when I type into a textbox, click somewhere else (also triggering the call) and swiftly click on the submit button, the call is also not made. Is that expected behaviour?
The reason I am using ajax in the first place is to persist the values so when something unforseeable happens, like a browser crash, the already typed in text is already saved.
Is my way of thinking wrong? How would you go about solving this problem?
Thank you for your time!
AJAX is asynchronous.
When you send an AJAX request the javascript engine sends it off and sets up a handler for the response.
However, if you send an AJAX request to the server and then navigate away from the page before it is received, nothing will happen. Why? Because with each page load the entire Javascript environment is tore down and reinitialized, it has no idea what happened on the last page.
For your problem I would intercept the form submit action and do whatever you need to do with the data, and then submit the form.
Edit: In response to your comment. You are correct. If the ajax request is sent, and you're not depending on it's return value, then it should not matter.
I'd suggest debugging your problem with Firebug to see if the AJAX call is really being sent properly, and to confirm your server is properly processing it.
Unless you do something special with persistent local storage, all javascript and ajax calls are blown away when a new page is loaded over the current page. Also when a submit is done on a form.
To save things intra-page, save the data asap. Eg, perhaps save on key-up, perhaps periodically with a timer, not just on lose-focus.
Re submitting the page: change the on-click behavior to first store, then to go to a new page.
All of the effects that you are seeing are normal.
Also, be sure to test on both slow (ie 6 or 7) and fast browsers (chrome)