Browse files

Moved default confirm and $.ajax functions to $.rails functions to al…

…low easy overriding/customization.
  • Loading branch information...
1 parent 50c06dc commit 8063d1d47ea6a08e545e9a6ba3e84af584200e41 @JangoSteve JangoSteve committed May 8, 2011
Showing with 12 additions and 2 deletions.
  1. +12 −2 src/rails.js
@@ -82,6 +82,16 @@
return event.result !== false;
+ // Default confirm dialog, may be overridden with custom confirm dialog in $.rails.confirm
+ confirm: function(message) {
+ return confirm(message);
+ },
+ // Default ajax function, may be overridden with custom function in $.rails.ajax
+ ajax: function(options) {
+ return $.ajax(options);
+ },
// Submits "remote" forms and links with ajax
handleRemote: function(element) {
var method, url, data,
@@ -105,7 +115,7 @@
data = null;
- $.ajax({
+ rails.ajax({
url: url, type: method || 'GET', data: data, dataType: dataType,
// stopping the "ajax:beforeSend" event will cancel the ajax request
beforeSend: function(xhr, settings) {
@@ -184,7 +194,7 @@
if (!message) { return true; }
if (, 'confirm')) {
- answer = confirm(message);
+ answer = rails.confirm(message);
callback =, 'confirm:complete', [answer]);
return answer && callback;

6 comments on commit 8063d1d


How does this work with a non-native confirm dialog? I would expect the $.rails.confirm handler to fire the 'confirm:complete' event and that $.rails listens for that and then continues on with the action, not that $.rails fires the 'confirm.complete' event itself? The problem with a non-native confirm dialog is that it doesn't return a value immediately...


I'm confused as to what you're asking. The only requirement for the confirm dialog being used is that it returns a true/false answer. If this is not the case for some particular confirm dialog, then $.rails.allowAction function would need to be modified (that is where the confirm and confirm:complete events are fired).


Right: "The only requirement for the confirm dialog being used is that it returns a true/false answer."
The problem is that with jQueryUI Dialog for example, it doesn't return a true/false answer immediately. Instead you have to define callbacks for the possible answers and the callbacks will be called once the user chooses an answer. So the answer is returned asynchronously. I don't see this working without, as you mention, overwriting the $.rails.allowAction function. So is that how it is supposed to work? Or should $.rails listen for a 'confirm:complete' event instead of firing it?


Yes, that is how it is suppose to work; confirm:complete is a custom event that gets fired by jquery-ujs, allowing you to bind some handler to execute with the answer passed in to the handler as data.

The allowAction function needs a synchronous answer in order to function properly. The point of the modal confirmation is that everything stops until the modal is confirmed. If you need to make it work with an asynchronous modal function ("asynchronous modal" being somewhat of an oxymoron), that requires a higher level of customization to the allowAction function.


Hmm, i don't think the required changes are limited to allowAction. If the answer to the confirm is returned asynchronously, then we need the allowAction followup actions to be asynchronously as well i think.

Here's quick and dirty code snippet of how i see this working (or something alongs these lines):

rails.allowAction(link, {
  allowed: function() {
    if ('remote') !== undefined) {
      return false;
    } else if ('method')) {
      return false;
  denied: function() {

And then call the confirm something like this:

rails.confirm(text, function(answer) {
  answer ? allowed.apply(...) : denied.apply(...);

Do you see a change like this being accepted into the code? If not, how do you see using a non-native confirm dialog working?


I'm not sure the jQuery UI confirm dialog could really even be considered a replacement for the javascript confirm dialog, in that it doesn't come close to behaving the same way. The two main characteristics of the confirm dialog are that it's blocking (i.e. synchronous) and returns true/false. And the jquery ui confirm function does neither. So I'm not sure this would be appropriate for pulling into core.

Though that's not to say this isn't a good way to implement it if your project calls for this. This is after all, why I opened up all the internal functions so that they could be easily customized.

It seems though like there should be some way to put a synchronous true/false interface on the jquery ui confirm function, I'm just not seeing it.

Please sign in to comment.