dataSource transport read success - but not really

[Richard]

I am working with a server that will return server side error messages in HTML but also have a response status of 200.

jqXHR.getAllResponseHeaders() returns

Server: Apache-Coyote/1.1

X-Powered-By: Servlet 2.4; JBoss-4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181417)/JBossWeb-2.0

x-ua-compatible: IE=EmulateIE7

X-SAS-STP-ERROR: -34

Cache-Control: no-cache, no-store

Content-Type: text/html;charset=UTF-8

Transfer-Encoding: chunked

Date: Fri, 11 Jan 2013 15:17:29 GMT

This is problematic since I need to check the X-SAS-STP-ERROR value

The RemoteTransport class has this important processing kernel in kendo.data.js:

result = cache.find(options.data);

 

if(result !== undefined) {

  success(result);

} else {

  options.success = function(result) {

    cache.add(options.data, result);

    success(result);   // I AM HERE

   };

   $.ajax(options);

} 

at the I AM HERE point the success handler is dispatched but is passed only the result, and thus the handler is missing the statusText and jqXHR (which are available as arguments[1] and arguments[2]).

So my issue is thus:
- Is there a better place to hook in my checks for X-SAS-STP-ERROR: -34 ?
- Should I patch the kendoui library to dispatch with success(result,arguments[1],arguments[2]) ?

- If the check for -34 asserts true is there a way the success handler can prevent/reject default success handling henceforth ?

Thanks,
Richard

[Richard]

My 'fix' for this requires a modification of the data module.

I had tried using jQuery global ajaxSuccess, but that routine is invoked _after_ the local success handler.

My understanding of the data module is that the The DS read: function queues up transport.read with a success handler proxied to its own instance.  Thus (correct me if I am wrong) out of the box there is an inability to install a custom success handlers via configuration settings.

The following tweak of RemoteTransport allows me to configure a handler at the pre-parse state.  My changes are noted with // RAD.

read: function(options) {

    var that = this,

        beforeParse, // RAD

        success,

        error,

        result,

        cache = that.cache;

 

    options = that.setup(options, READ);

 

    beforeParse = options.beforeParse || noop; // RAD

    success = options.success || noop;

    error = options.error || noop;

 

    result = cache.find(options.data);

 

    if (result !== undefined) {

        success(result);

    } else {

        options.success = function(result, status, jqXHR) { // RAD add status and jqXHR

            //RAD

            if (true !== beforeParse(jqXHR,error)) {

              cache.add(options.data, result);

              success(result);

            }

            //RAD

        };

 

        $.ajax(options);

    }

},

Then I can use this transport configuration to specify the beforeParse handler

    transport: {

...

        read: {

...

            , beforeParse: checkResponse

        }

    }

Which is implemented (in my case) to fail if a certain header is observed

function checkResponse(jqXHR,error) {

    if (jqXHR.getResponseHeader('X-FOOBAR-ERROR')) {

        raiseWindow(jqXHR.responseText);

        error(jqXHR,'error','X-FOOBAR-ERROR');

        return true;

    };

}

The beforeParse property might be better named as preventDefault.