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.
Related
I am trying to create a web form in Lotus Notes that is web enabled. So far this has all worked fine, however there are 2 issues.
When Creating a Java Script Alert in the OnLoad Event, it Pops up everytime a user selects a radio button or dropdown option since this reloads the page. Is there any way to make this only for the initial opening of the form?
When a user selects an option, the form reloads and puts that form field on the top which is proving to be very disorrienting for users. Is there a way to have it not scroll on reload?
Thanks in advance!
The best advice would be: use XPages for web development that is "state of the art". If you can't, you have to code a lot of JavaScript to make the form not behave like "havoc".
First of all: the field property "refresh fields on keyword change" is the reason for the jumping / reload.
What does domino do?
All events / formulas that occur when you normally press F9 or use the Option above (that can be field values, input translations, hide whens, etc.) are not "converted" to HTML and javascript but are executed by the server. Therefor each change in a field with the option set submits the form and adds an &Seq=x to the url to keep track of the state. X increments on every reload. Of course this reload causes all events to be triggered again.
For you this means:
Option
disable the option to reload the form after keyword change.
Unfortunately you have to recode every dependency / calculation / hide when with javascript. Using a framework like jquery or dojo this is possible, but a lot of work.
If there IS no dependency then just disable the option...
Option
Live with the "jumping" and let your onload event check for the existance of an URL- parameter called seq... And only if it does not exist, then it is a "real" OnLoad...
Both options are not quite nice and not very easy to code...
That's one reason why IBM started XPages... There all this stuff is already handled by default...
There is a strange back button behavior occurring only in Chrome.
I have two pages - Grid and a Form
the scenario:
1. When navigating from the Grid to the Form everything is fine - the Grid is added to the history.
2. When the Form is sent to the server via post, i use RedirectToAction to redirect(302) to the Grid again - the Form is added to the history.
3. When navigating again from the Grid to the Form after the redirect, a history point containing the Grid address is not added to the history
Now you have to click twice on the back button to get back to the grid.
if you repeat all the steps several times and watch the history stack you will see a sad list of Form entries without the Grid in the middle
edit: here is a link to a page demonstrating the problem, open it in chrome and follow the instructions - see the Chrome history bug in action
The only "Solution" i found for this is putting some random crap in the link to the Form, but i really hate this.
Chrome is strict about using HTTP 303 See other while your application uses 302 Found for redirects. See a related chrome bug report here: http://code.google.com/p/chromium/issues/detail?id=2801
You can vote to fix ASP.Net MVC's RedirectToAction here: http://connect.microsoft.com/VisualStudio/feedback/details/706961/asp-net-mvc-controller-redirecttoaction-method-should-return-http-303-response
1) I saw an interview question on this, and I'm assuming it's something to do with form submission and avoiding double submissions. Can someone confirm this?
2) Assuming this assumption is correct, can this be done with Ajax? If so is there a link someone can point me to?
(I'm assuming you'd generate some sort of random number and include it in the form as a hidden field, then ensure that number hadn't been submitted before for the session).
Redirect-after-post is a technique to avoid problems with the user refreshing or using the back button to get back to a posted form. In short, instead of providing a response page to an HTTP post, which will trigger another post if its reloaded, you issue a 303 redirect (or a 302, to support ancient browsers by taking advantage of a bug that is as old as the web). This causes the browser to issue a second HTTP request - a get this time - and if the response page to that is reloaded there shouldn't be any problems. Just make sure that all the changes are made by the post handler and the page you redirect to has no side effects.
If you post using XMLHttpRequest then the redirect will be followed; unless you specifically support it using the hash part of the location or the new HTML5 history methods then the back button and reload aren't going to trigger an AJAX post again.
I've search high and low for an answer to this but unfortunately I'm stuck. The problem is only occuring in Firefox (tested IE, Chrome and Safari also - works fine, no errors of any sort). I'll detail the sequence of events to save posting all my code.
ASP.NET MVC 3 application, basic form loads into a jQuery UI dialog
Custom jQuery to hijax the form submit (serialize the form and then $.post to the server - no compiler errors when debugging and post shows up in Firebug without errors)
Http GET (automatically happens) getting the response object from the server (+ success text and XHR), response is plain HTML in this case (again, shows up in Firebug with no errors)
Custom jQuery to change the HTML of the UI dialog from it's current HTML to the response Html - this is where it fails.
I've used javascript alerts to debug the sequence of events and as soon as the post (and get) is complete, everything just... sort of stops.
As I say, only in firefox! Very odd, just wondering if there's any known bugs with ajax and firefox or anybody has heard of a similar situation?
I must also add, that on other parts of my site, this works perfectly in all browsers! The only difference between this form and the other forms that do successfully complete the function is that the response from this form is the same "page" again but updated rather than a new "page". (I use "page" as I got all this working with Javascript turned off first and for graceful degredation)
HELP! Or laugh, either is fine.
UPDATE
I have tried sending a view with a blank model back as the action result - works in every browser except firefox - firefox retains the values from the previous post! And then I got to thinking - that's a trait of firefox isn't it? And maybe that's why the original "re-direct" html response doesn't work?? I think it's time to give up and let people know they can't use Firefox for that particular function!
Ok so I'm answering my own question.
The only way I found to get round it is to use $.ajax instead of $.post and to use the option async : false
Hope this helps somebody.
Rob
Have you tried adding the attribute [OutputCache(Location = System.Web.UI.OutputCacheLocation.None)] to your Action for your GET? It sounds to me like a caching issue.
The problem is this:
When I change the content on a page via AJAX and then use the browsers back and forward button to go to the same page, then I will be presented with the content of the page before the AJAX was executed.
This seems to be specific to IE (confirmed on version 8), as Firefox will render the last version of the page.
Just to clarify, I don't need (nor want for usability reasons) to replay the AJAX calls when clicking back/forward.
We were thinking about firing the last AJAX call on page load (if that event is even triggered), but we would like not to force everyone to wait through the additional AJAX call when going to the page the second time, also this would cause the first real load of the page to be slower as well.
Maybe someone has a good solution for this?
I think it will be useful : http://www.ibm.com/developerworks/library/os-php-rad2/ ;)