Results 1 to 7 of 7

Thread: store load error different in 6.2 and 6.7

  1. #1
    Sencha Premium User
    Join Date
    Jan 2017
    Posts
    7

    Default store load error different in 6.2 and 6.7

    in 6.2 I could see what the exact server response was, when it returned invalid json for a store load

    myStore = Ext.create("Ext.data.JsonStore", {
    fields:[
    ....
    ],
    proxy:{
    type:"ajax",
    url:...l,
    listeners:{
    beginprocessresponse:function(store,response) {
    try {
    Ext.JSON.decode(response.responseText)
    } catch {
    <display response.responseText>
    }
    }
    }
    })

    in 6.7 response.responseText doesn't exist anymore. I can only see that response.responseJson is null, when the server has returned invalid jSon. But I don't see what it actually returned. How can I discover what it really sent back?

  2. #2
    Sencha User
    Join Date
    Sep 2007
    Location
    Phoenix AZ
    Posts
    120
    Answers
    5

    Default

    There are a couple places you can find what the server is sending back.

    If you are using chrome you can use the developers tools (menu -> more tools -> developer tools) click on "network" at the top of the developer tools window. You can watch the conversation between client and server. Headers on each ajax call and the response.

    You are directing the ajax call to a server I assume your server. So what are you sending back from the ajax call .... the HTTP request you are sending the server?

    If I had to guess, there is an error on the server and it is returning no data just a status code 404 or 400 or some other http error status code. Could be that the new version is sending the data to the server differently and causing the error. And you can check this as well via the developers tools in chrome.

    I generally check for this kind of error in the callback method of the store load method. I have never used the beginprocessresponse event.

    This is some basic stuff so forgive me if I misunderstand your question.

    -Mark

  3. #3
    Sencha Premium User
    Join Date
    Jan 2017
    Posts
    7

    Default

    Thanks Mark. Yes, I can see what goes wrong in Chrome. The error console shows something like this:

    Parse error: syntax error, unexpected 'function' (T_FUNCTION) in /virdir/apps/www_root/georef/georef67.php on line 4


    But I would like to see this message in the Ext application itself. In a regular Ajax call (Ext.Ajax.request), that is not a problem, I just test response.responseText before I do any further processing. But a Json store expects Json from the server. When that is not the case, it just silently aborts. I tried everything: testing the response in the store's load event, writing an exception function for the json proxy, but I cannot manage to see what the server returns in case of an error. In 6.2 I could use the undocumented "beginprocessresponse" event, but that doesn't work anymore in 6.7.

    So how do I debug an aborted json store load?

  4. #4
    Sencha Premium User mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    40,379
    Answers
    3997

    Default

    There was a change (cannot remember if it was 6.6 or 6.7) but you can get the already decoded JSON using response.responseJson. When it's present, I believe response.responseText will not be there.
    Mitchell Simoens @LikelyMitch

    Check out my GitHub:
    https://github.com/mitchellsimoens

    Posts are my own, not any current, past or future employer's.

  5. #5
    Sencha Premium User
    Join Date
    Jan 2017
    Posts
    7

    Default

    But that is exactly the problem. When the server returns invalid jSon for a Json store, I cannot get at that data. I looked in:

    - the exception event of the store's proxy and the global requestexception event of the Ext.Ajax object. Those ones do get triggered when the server returns an http error code. They have a field responseJson, which is filled when the server has returned valid Json, and null when not.
    - the (undocumented) beginprocessresponse event of the store's proxy. That one always gets triggered, with or without http error code. In 6.2 it had the server response as response.responseText. In 6.7 it only has response.responseJson, which is null when the server has returned invalid Json.

    As Mark said, I can see what the server returns in the Chrome console. But for quick debugging, I would prefer to be able to see it in ExtJS itself.

    I'm sure I'm missing something, but I never have been able to handle invalid server data for a Json store to my liking. From 6.7 I am not able to do so at all. Any help would be much appreciated!

    Jan

  6. #6
    Sencha Premium User mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    40,379
    Answers
    3997

    Default

    So I found out where the changes are and even though parts of the code aren't what I would have done, I did find a simple way to create an override that you can remove the property that will control this. Here is an example with an override that will keep the out of the box behavior but you can disable this so you can get responseText back:



    Also note, if the JSON is invalid it will throw an error using Ext.raise which is a nice benefit since it used to fail silently and you'd have to handle this yourself iirc.
    Mitchell Simoens @LikelyMitch

    Check out my GitHub:
    https://github.com/mitchellsimoens

    Posts are my own, not any current, past or future employer's.

  7. #7
    Sencha Premium User
    Join Date
    Jan 2017
    Posts
    7

    Default

    YES, this works, and I can debug server-returned faulty Json for a store. I see that from 6.7 on Json keys have to be quoted (not: {numRecords:2379} but {"numRecords":"2379"}. I am always glad to improve my bad habits, but they really have to be pointed out to me, else I won't know them :-).

    IMHO this should be the default behavior: an exception should *always* be raised when a store load fails, and the raw responseText should be returned. Is there a place where I could submit this?

    Thanks a big lot, Mitchell, this saves me considerable head banging in the future. I certainly owe you a beer :-)

    Cheers,

    Jan Hartmann
    Amsterdam

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •