#334 ✓not_for_core
Darrin Holst

onSuccess/Failure not dispatched to Ajax.Responders

Reported by Darrin Holst | September 10th, 2008 @ 05:08 AM

It was pointed out over on the Prototype & script.aculo.us group that registering an onSuccess, onFailure, or even onXXX handler with the Ajax.Responders does not work. The patch attached fixes that.

One difference between the normal callbacks and the global callbacks is that the onXXX will not short circuit the corresponding onSuccess or onFailure callback. My assumption is that if you're registering on500 and onFailure globally that you want both called.

Comments and changes to this ticket

  • John-David Dalton

    John-David Dalton September 10th, 2008 @ 08:03 AM

    Here is another way to reduce some of the code something like...

    Updated

    
    
      respondToReadyState: function() {
        var response = new Ajax.Response(this),
         state = Ajax.Request.Events[response.readyState],
         dispatchers = [], skipped = { };
    
        if (state === 'Complete') {
          this._complete = true;
          var succOrFail = this.success() ? 'Success' : 'Failure';
          dispatchers.push(response.status, succOrFail);
    
          if (this.options['on' + response.status])
            skipped[succOrFail] = true;
    
          // avoid memory leak in MSIE: clean up
          this.transport.onreadystatechange = Prototype.emptyFunction;
    
          // handle returned javascript
          var contentType = response.getHeader('Content-type');
          if (this.options.evalJS == 'force'
             || (this.options.evalJS && this.isSameOrigin() && contentType
             && contentType.match(/^\s*(text|application)\/(x-)?(java|ecma)script(;.*)?\s*$/i))) {
            this.evalResponse();
          }
        }
    
        dispatchers.push(state);
        dispatchers.each(function(name) {
          try {
            if (!skipped[name] && this.options['on' + name])
              this.options['on' + name](response, response.headerJSON);
            Ajax.Responders.dispatch('on' + name, this, response, response.headerJSON);
          } catch (e) {
            this.dispatchException(e);
          }
        }, this);
      }
    
  • Darrin Holst

    Darrin Holst September 10th, 2008 @ 03:07 PM

    It looks like you've taken out on[response.status]. I was going add it to your example, but couldn't fit it in where it looked any better than it did before.

  • John-David Dalton

    John-David Dalton September 10th, 2008 @ 03:39 PM

    Thanks, I missed that one :) (I have edited the post to reflect the change)

  • Darrin Holst

    Darrin Holst September 10th, 2008 @ 04:13 PM

    Now an on404 registered on Ajax.Responders is only going to get called if you have an on404 set on the Ajax.Request, right?

    Or, probably a more common scenario, an onFailure registered on Ajax.Responders won't get called if you have an on404 registered on the Ajax.Request (and get a 404).

  • John-David Dalton

    John-David Dalton September 10th, 2008 @ 04:21 PM

    Correct.

    onXYZ [from docs]

    With XYZ being an HTTP status code for the response. Invoked when the response just completed, and the status code is exactly the one we used in t he callback name. Prevents execution of onSuccess / onFailure. Happens before onComplete.

  • Darrin Holst

    Darrin Holst September 10th, 2008 @ 04:35 PM

    Correct in that's the way you want it to work?

    The way I would expect it to work is if you register one or many global callbacks those callbacks should be called regardless of the options you gave to the individual Ajax.Request.

    Contrived example:

    
    Ajax.Responders.register({
      onFailure: countFailuresForSomeReason
    })
    
    new Ajax.Request('foo', {
     on400: doSomethingSpecialForBadRequest
    }
    

    So if I get a 400 on the 'foo' request my failures counter doesn't count that one?

  • John-David Dalton

    John-David Dalton September 10th, 2008 @ 06:21 PM

    good point, I modified my example again :)

  • Tobie Langel

    Tobie Langel September 10th, 2008 @ 08:59 PM

    An upcoming revamp of ajax.js should/will include making the requests dispatch custom events and deprecating Ajax.Responders.

    We can keep current responders alive (maybe in a separate plugin) for backwards compatibility. These would just be listening for custom events on the document.

    As this should be deprecated, we should no longer be modifying or adding to its API.

  • John-David Dalton

    John-David Dalton September 10th, 2008 @ 10:07 PM

    • State changed from “new” to “not_for_core”
  • Tobie Langel

    Tobie Langel July 24th, 2009 @ 01:54 AM

    • Tag changed from ajax, patched, tested to patched, section:ajax

    [not-tagged:"ajax" tagged:"section:ajax" bulk edit command]

  • Richard Quadling

    Richard Quadling September 29th, 2009 @ 09:56 AM

    I have a similar feature request at http://dev.rubyonrails.org/ticket/9690.

    One addition is that the onXYZ callbacks can inhibit the calling of the onSuccess/onFailure callbacks.

    Over 2 years ago!

  • Terence Mitchell

    Terence Mitchell April 5th, 2018 @ 07:58 AM

    Concentrated to Gram Panchayats which is the lowest tier of the three-tier panchayatguru The concerned Gram Panchayats themselves publish these reports directly to the website.

  • Uposend255

    Uposend255 April 7th, 2018 @ 11:21 AM

    And within just a blink of an eye, you obtain the best capture of the photo www.snapchat.com Snapchat has conquered our daily routine No day goes by if you do not post a selfie below.

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

The Prototype JavaScript library.

Shared Ticket Bins

Attachments

Pages