Results 1 to 10 of 10

Thread: [CLOSED-EXTJSIV-437]REST request: success = true despite server return false

    Thank you for reporting this bug. We will make it our priority to review this report.
  1. #1
    Ext JS Premium Member htammen's Avatar
    Join Date
    Jul 2010
    Location
    Germany, Hannover
    Posts
    74

    Default [CLOSED-EXTJSIV-437]REST request: success = true despite server return false

    response_true.png

    as you can see in the screenshot above my server returns "success: false" but the operation success property is set to true.
    Therefore my success handler rather than the failure handler is called.

    This happened in ExtJS 4 Pr4

  2. #2
    Sencha User
    Join Date
    Feb 2011
    Posts
    106

    Default

    I can confirm this is a bug. It has been confusing me for hours as older documentation says to send this kind of data structure:

    [{"success":false,"id":"FirstName","msg":"You Broken"}]

    This is a annoying bug because I am trying to work on my error / exception handling now. The only way (without digging into Extjs source) to work around the issue is to add to my Model an "errors" field. I would rather not do this.

    Second thing I might add is with models we should be saying "field" and "message" rather than "id" and "msg". I just want to make sure that if this bug is fixed, that if I send an errors JSON structure to either a form failure handler, or a Model failure handler that I expect it to deserialize and be there!

  3. #3
    Sencha User
    Join Date
    Feb 2011
    Posts
    106

    Default

    Ok, I am totally floundering here! Help!

    How are we supposed to get Model Errors back to the form, API wise? I can't figure out what the intention was.

    This is what I am calling, in my basic form, within a Save button click event:
    Code:
     myModel.save({
                        success: function(form, action) {
                           //Do Something?
                        },
                        failure: function(form, action) {
                          //Do Something?
                        }});
    As this bug states setting the success property does nothing. Infact look at this snippet of ExtJS 4 code:

    Code:
    parseStatus: function(status) 
    {
        status = status == 1223 ? 204 : status;
        
        var success = (status >= 200 && status < 300) || status == 304,
        isException = false;
        
        if (!success) 
        {
            switch (status) {
                case 12002:
                case 12029:
                case 12030:
                case 12031:
                case 12152:
                case 13030:
                isException = true;
                break;
            }    
        }
        
        return {
        success: success,
        isException: isException};
    }
    Notice how there is no parsing of the success property? I don't know if ExtJS 4 was meant to use the success property (in returned data from the server). There is no documentation, so I looked at some old docs stating you needed to set the success property with HTTP code of 200.

    Ok, so then I set my code (on my server) to 444 and it did hit the failure callback handler. Good!

    But what next?

    To get validation rule errors I sent back this data structure from my server:

    Code:
    [{"success":false,"field":"FirstName","message":"You Fail"}]
    But I will be darned on what I am supposed to do next in the failure callback handler (see above).

    Oh, and yes I know I can return an error object as part of my data structure (define it in the model) and then manually access that in the success handler.

    I don't think I should have to do that. That just seems wrong to me to have an errors field on my Model for validation. If that is the way ExtJS 4 intended it I will do it. But I think there is such a lack of documentation in this area and this is why I am lost.

    I have yet to venture down the "exception" route. I am sure I could skip the validation stuff and move on for now to exceptions. It looks like there is a action.getError() I can do for them.

    But I must ask... Why are these codes the magical codes to tell Extjs that it is an exception:
    case 12002:
    case 12029:
    case 12030:
    case 12031:
    case 12152:
    case 13030:

    They seem totally random, and they all do the same thing. Well, it looks like Exceptions might be working (based on what I see in the source code)... I guess until I get more direction I can move on to that.

    Help!

  4. #4
    Sencha User Jamie Avins's Avatar
    Join Date
    Mar 2007
    Location
    Redwood City, California
    Posts
    3,661

    Default

    WinInet Error Codes, here are some for reference:

    http://support.microsoft.com/kb/193625

  5. #5
    Sencha User
    Join Date
    Feb 2011
    Posts
    106

    Default

    Thanks for that! That is very helpful!

  6. #6
    Sencha User
    Join Date
    Feb 2011
    Posts
    106

    Default

    How is everyone else using the model and form validation? Has anyone got validation errors coming back from the server to the success or failure callback on save? Maybe it was never indented to work with the model and the success/failure method?

    Maybe that whole validation error thing only works if you actually save on the form? Hmmm... It would not surprise me since there is very little that works between the model and the form. I guess I figured a success or failure callback would parse the JSON the same way regardless of if I did it in a form or a model.

    Even if it did work, it's not clear what property or method I would check after a save, in the success or failure callback for validation errors on the model.

    Thoughts?

  7. #7
    Sencha Premium User evant's Avatar
    Join Date
    Apr 2007
    Location
    Sydney, Australia
    Posts
    19,256

    Default

    Specify a root on the reader. If you return success: false as part of your model, there's no way to tell the difference between it being a field or the success property.

    Code:
    {
        "success": false,
        "data": [{
            // model stuff
        }]
    }
    Twitter - @evantrimboli
    Former Sencha framework engineer, available for consulting.
    As of 2017-09-22 I am not employed by Sencha, all subsequent posts are my own and do not represent Sencha in any way.

  8. #8
    Sencha Premium User evant's Avatar
    Join Date
    Apr 2007
    Location
    Sydney, Australia
    Posts
    19,256

    Default

    Code:
    Ext.require('Ext.data.*');
    
    Ext.define('SomeModel', {
        extend: 'Ext.data.Model',
        fields: ['id', 'a', 'b', 'c'],
        proxy: {
            type: 'rest',
            url: 'data.json',
            reader: {
                type: 'json',
                root: 'data'
            }
        }
    });
    
    Ext.onReady(function(){
    
        var rec = new SomeModel({
            id: 1,
            a: 'x',
            b: 'y',
            c: 'z'
        });
        
        rec.save({
            success: function(){
                console.log('so good');
            },
            failure: function(){
                console.log('no good');
            }
        });
    
    });
    Code:
    {
        "success": false,
        "data": {
        }
    }
    Twitter - @evantrimboli
    Former Sencha framework engineer, available for consulting.
    As of 2017-09-22 I am not employed by Sencha, all subsequent posts are my own and do not represent Sencha in any way.

  9. #9
    Sencha User
    Join Date
    Feb 2011
    Posts
    106

    Default

    I saw in the beta 1 release notes this little gem:

    "Added HTTP error info to the data operation when a request fails"

    This is workable for exceptions server-side. I can, in MVC ASP.NET, change error codes and the "statusText" to whatever I want. This is a very useful addition! Thanks! With .NET ELMAH error logging and a custom ErrorHandler, I will be able to make ExtJS a first class citizen to all really bad exceptions that happen on my server. I think this is the best thing to be added in Beta 1!!!

    Now for the success property. That is helpful to know that the save failed. But what am I supposed to do in the case it's false? I don't know why it's false. The user does not know why it's false.

    I have been able (with the awesomeness of the extendability features of ExtJS) to create a nice remote validation add-on, for onBlur for form fields. But this is just a "nicety". You could never trust that. You want to make sure when our model is false, on the server, you tell the user why it's an invalid model. This is way different than an Exception. Yes, I could throw a exception, and set the statusText to say why the model failed to save. But if it's a validation issue, it feels just wrong to misuse exceptions in this case. Plus it would be nice if I could flag fields as broken on my form....

    If it was a failure of validation rules (server-side only rules), shouldn't there also be a way to get those errors after the save is complete, so that I can inform the user of what field failed (I can format the JSON to be an errors object)? I guess I could add an errors field to my model. It just seems wrong, because then if I do another save, it's going to try and serialize those validation errors up to the server...

    To me the ideal solution would be, if I do a save, what would return in the failure callback, would be the successProperty = false and an errors object that I would have access to. Then I could go on my merry way setting the form with the errors, or throw up a message box iterating over the errors.

  10. #10
    Sencha User
    Join Date
    Nov 2010
    Posts
    13

    Default

    So, the last reply is about half a year ago. Has anyone got a workaround for this? Is our only solution to generate an HTTP error code from the server (i.e. by throwing an unchecked exception out of a Java web server or something similar)? ExtJS 3.3 had a nice little "errorProperty" you could set for your store, and upon the server returning a false for the successProperty, you could dynamically pull the error message from the server through this messageProperty value. This functionality seems to have been removed from ExtJS 4.x., making it necessary to either define the error messages in the model itself (which is not ideal as wizkid notes), or to ensure the server is returning non 2xx HTTP statuses. Neither of these is particularly desirable.

Similar Threads

  1. store success true false
    By bkraut in forum Ext 3.x: Help & Discussion
    Replies: 10
    Last Post: 4 Jan 2011, 5:51 AM
  2. [CLOSED]XmlReader always return success=true
    By inttlt in forum Ext 3.x: Bugs
    Replies: 3
    Last Post: 28 Oct 2009, 1:06 AM
  3. error on 'success:false' form return
    By Mitaka in forum Ext 2.x: Help & Discussion
    Replies: 10
    Last Post: 17 Feb 2009, 8:37 AM
  4. form, json: success: true/false
    By bartvde in forum Ext 2.x: Help & Discussion
    Replies: 1
    Last Post: 8 Nov 2007, 12:40 AM

Posting Permissions

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