Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#15635 closed defect (invalid)

Dojo1.8.0b1: dojo.request.notify not working?

Reported by: Paul Christopher Owned by: Bryan Forbes
Priority: undecided Milestone: tbd
Component: IO Version: 1.8.0b1
Keywords: Cc:
Blocked By: Blocking:

Description

I think I have tried everything as described in the livedocs, but request.notify doesn't work for me: I do not get a send-event for some reason, see attached test case (taken from an ASP.net project).

Ajax works well, but the topic seems never to be published.

By the way: There is a typo in the "Usage" section showing how to subscribe to the send-event:

topic.subscripe("dojo/request/send", function(data){
    // Do something on "dojo/request/send"
  });

I think it should "topic.subscribe" and not "topic.subscripe".

Attachments (2)

Index.cshtml (1.3 KB) - added by Paul Christopher 7 years ago.
testAbort.cshtml (1.4 KB) - added by Paul Christopher 7 years ago.
test case showing problem of aborting a request within the topic subscriber and getting to know abort reason in error callback

Download all attachments as: .zip

Change History (6)

Changed 7 years ago by Paul Christopher

Attachment: Index.cshtml added

comment:1 Changed 7 years ago by bill

Component: CoreIO
Owner: set to Bryan Forbes

comment:2 Changed 7 years ago by Bryan Forbes

Resolution: invalid
Status: newclosed

The documentation at livedocs is wrong in that topics should be prefixed with "/". This means using "/dojo/request/send" rather than "dojo/request/send". However, the interface to dojo/request/notify is changing and will be a dojo/Evented interface soon and the docs will be updated accordingly.

comment:3 Changed 7 years ago by Paul Christopher

Bryan, you are prefectly right: Prefixing the topic with "/" fixes it. My test file works now, and I can cancel/ abort the request "from the outside", i.e. within the topic subscriber. However one problem remains: It seems that there is no way to pass a custom error message/ reason for aborting with the xhr.abort function.

Aborting an xhr request triggers the xhr's error callback but within this error callback there seems to be no way to properly figure out the error's reason. When aborting from the outside, every browser throws a different error message, FF13 a "Cannot modify properties of a WrappedNative", Safari an "INVALID_STATE_ERR: DOM Exception 11".

Could it be possible to implement something like this:

xhr.abort('SessionTimeout');

so that I can do something like this in the error callback:

xhr.post('http://test.com', options).then(function (response) {
   ...
   }, function (error) {
      switch(error.message) {
         case 'SessionTimeout':
                    ....
         default:
                    ....
      }
});

comment:4 Changed 7 years ago by Paul Christopher

The IO pipeline topics used to publish the deferred, too. I can't see a deferred being passed to the callbacks of request.notify. Why? What if I do not want to abort but just reject/resolve the request within the request.notify.send callback?

Changed 7 years ago by Paul Christopher

Attachment: testAbort.cshtml added

test case showing problem of aborting a request within the topic subscriber and getting to know abort reason in error callback

Note: See TracTickets for help on using tickets.