Thank you for reporting this bug. We will make it our priority to review this report.
  1. #1
    Sencha User
    Join Date
    Feb 2011
    Posts
    106
    Vote Rating
    2
    wizkid is on a distinguished road

      0  

    Default [FIXED-EXTJSIV-292] Bug with Ext.form.Basic.markInvalid w/ an error object

    [FIXED-EXTJSIV-292] Bug with Ext.form.Basic.markInvalid w/ an error object


    Strait from the documentation:

    markInvalid( Array/Object errors) : Ext.form.Basic

    Now consider this snippet
    Code:
    handler: function () 
    {
                mySimpleForm.getForm().updateRecord(singleUserModel);
    
                var errors = singleUserModel.validate();            
    
                if (errors.isValid()) 
                {
                    //handle success
                }
                else {
                    mySimpleForm.getForm().markInvalid(errors);
                }
            }
    When I pass in a error object it does not work correctly. It does not flag my form field with an error halo. I went deep into the code through a debugger. Looks like there are some problems with iterating over this error object (again we are going deep here, and I don't really want to understand all that was going wrong)...

    Anyway, I came up with a quick fix that probably breaks the API for when you want to pass a array into markInvalid instead of a error object.

    In ext-all-debug.js find this: markInvalid: function(errors)

    Code:
    markInvalid: function(errors) {
            var me = this;
    
            function mark(fieldId, msg) {
                var field = me.findField(fieldId);
                if (field) {
                    field.markInvalid(msg);
                }
            }
    
            if (Ext.isArray(errors)) {
                Ext.each(errors, function(err) {
                    mark(err.field, err.message);
                });
            } else {
                Ext.iterate(errors, mark);
            }
            return this;
        },
    And copy and paste what I have above over top of it.

    Basically I changed this line mark(..., ...); to the field names in the error object.

    Then in your form do this:
    mySimpleForm.getForm().markInvalid(errors.items);

    This works because you are passing in the array instead of the whole errors object.

    You will now get halos around your controls that have errors!!! I am sure Sencha will come up with a better fix. But for now this allows me to move on!

  2. #2
    Ext JS Premium Member
    Join Date
    Apr 2010
    Location
    Omaha, NE
    Posts
    557
    Vote Rating
    25
    estesbubba will become famous soon enough estesbubba will become famous soon enough

      0  

    Default


    Yes, I found the same problem and posted this in the other thread.

    So debugging the code shows markInvalid wants 'id' and 'msg' but errors.items contains 'field' and 'message'. It appears to be the same data just with different field names. So is the best solution to iterate over errors.items and build a new object with the desired names? Easy to do but will get repetitive for all form validation. I would think that if a form uses a model, it should be able to understand the model's errors.

    For now I ended up writing a method to create the proper object to pass to makeInvalid. Hopefully this is a temporary solution.

  3. #3
    Sencha User
    Join Date
    Feb 2011
    Posts
    106
    Vote Rating
    2
    wizkid is on a distinguished road

      0  

    Default


    Ahhh, I missed that post some how. Anyway, I think there needs to be a binding class for ExtJS. I assumed this was there before I started my project. My mistake ....

    Anyway, conceptually I should not have to call markInvalid, updateRecord and loadRecord, etc. This is just too noisy on any platform. From a functional stand point we can work around this for now. But from a architectual stand point a robust binding class would make ExtJS 4.0 killer!

    +1 for this feature in the future. If it was up to me I would wait to release 4.0 until this feature is added. That's how important I rate binding. From my vantage point once you add a true "Model" that's when you need to also bring to the table some sort of "binding" to UI controls. I don't know if I have the time in my project to go too deep into creating something like that. I have spend enough time already working through pre-release issues... Not complaining... But boy what I would give for binding in extjs 4!

  4. #4
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    37,327
    Vote Rating
    850
    mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute

      0  

    Default


    Problem is that not every use case warrants omnidirectional binding. I think it would be extremely useful but I'm fine with using the existing methods.

    If you want the binding, create a plugin and release it That is a great way to give back to the community and will also teach you the inner workings of the framework.

    About the original bug, create an override until it gets fixed.
    Mitchell Simoens @SenchaMitch
    Sencha Inc, Senior Forum Manager
    ________________
    Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
    https://github.com/mitchellsimoens

    Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/

    Need more help with your app? Hire Sencha Services services@sencha.com

    Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is in print!

    When posting code, please use BBCode's CODE tags.

  5. #5
    Ext JS Premium Member
    Join Date
    Apr 2010
    Location
    Omaha, NE
    Posts
    557
    Vote Rating
    25
    estesbubba will become famous soon enough estesbubba will become famous soon enough

      0  

    Default


    Now I'm at work, here is the simple method I wrote.

    PHP Code:
            translateErrors: function(recErrors) {
                var 
    errors = [];

                
    Ext.each(recErrors.items, function(item) {
                    
    errors.push({
                        
    iditem.field,
                        
    msgitem.message
                    
    });
                });
                
                return 
    errors;
            } 

  6. #6
    Sencha User
    Join Date
    Feb 2011
    Posts
    106
    Vote Rating
    2
    wizkid is on a distinguished road

      0  

    Default


    Quote Originally Posted by mitchellsimoens View Post
    Problem is that not every use case warrants omnidirectional binding. I think it would be extremely useful but I'm fine with using the existing methods.

    If you want the binding, create a plugin and release it That is a great way to give back to the community and will also teach you the inner workings of the framework.

    About the original bug, create an override until it gets fixed.
    I agree totally that it should be an option. I would argue though that the majority would need/want omnidirectional two-way binding. I agree it would be a good community plugin if ExtJS does not do it for the 4.0 release. I wish I had the time. I really need to finish this project and not fool around with creating binding classes. If I knew how long it would take I could do a time/cost analysis. I am afraid if I do it I will be running into allot of pre-release bugs, like I have thus far (this tends to drain time from productive things).

    I don't know the end from the beginning. I know I have said this before. But the second you add a fully featured Model then to me (and most frameworks on other platforms do this BTW) the natural expected feature is some sort of "binding" without the noise of setting and getting and validating manually. Doing that produces messy code, IMHO. ExtJS has given us helper methods to get by. That's fine. But to me this shows an symptom of a architectural problem (we are missing something key).

    Any platform I have used, that provides binding, with models always had the ability to not use them. So no worries there... I won't force you to do it my way

  7. #7
    Sencha User
    Join Date
    Feb 2011
    Posts
    106
    Vote Rating
    2
    wizkid is on a distinguished road

      0  

    Default


    This is still broken in Preview Release 4. I don't know if anyone said it was fixed for Preview 4... I just thought I should report that the issue remains.

  8. #8
    Sencha User
    Join Date
    Feb 2011
    Posts
    106
    Vote Rating
    2
    wizkid is on a distinguished road

      0  

    Default


    Small update with Preview Release 5...

    I have a specific textfield instance and then I call markInvalid(...), from within the blur event handler, passing an errors object (the reason I am doing it is due to required updateRecord(...) and validate() for my model). Anyway, it correctly shows the error halo. But the message is all messed up. It says

    "[object
    Object]"

    Also, the message is visually breaking out of the tool-tip error hover box. I don't know if this is related to the Form's markInvalid(...) bug, but I figured I would report it.

  9. #9
    Sencha - Architect Dev Team jjohnston's Avatar
    Join Date
    Sep 2010
    Posts
    567
    Vote Rating
    20
    jjohnston will become famous soon enough jjohnston will become famous soon enough

      0  

    Default


    Thanks for the suggestion and discussion around this. As a short-term convenience we have added support to Ext.form.Basic.markInvalid to make it accept a Ext.data.Errors object in addition to the old formats.

    We also agree that having a full-featured framework for automatically binding data models and stores to forms is worthwhile, and have added that to our queue of features to be added post-4.0.

  10. #10
    Sencha User
    Join Date
    Jul 2008
    Posts
    53
    Vote Rating
    0
    jash is on a distinguished road

      0  

    Default


    +1 for this feature (binding models to forms etc.)

    BUT:

    I personally think it would be an ESSENTIAL part of the 4.0 release.

    My Case:

    we have my own extensive backend written in Python and Using SQLAlchemy (database independent ORM and more). Each python class where members are to be edited should be able to output its own Model and View (No not MVC).

    the model is an ext.regModel line based on the Python object and "auto generated", easy..... using introspection

    the "view" is basically a formPanel with the just mentioned model and validations. NO associations are used because:

    - Their fucntionality is far, far and I mean far away from being usable in serious applications where data integrity is needed (and this should be handled on the database server, no where else!!!!)

    - Very limited association model. ie. I use polymorphic tables etc.

    Although 4.0 has many good things over 3.x. So we have put stuff on hold and are waiting (and learning/testing/playing) with 4.0. It was supposed to be there end of february, now it is the end of march still no Beta, confusing Documents, most of the functionality (we need) is (still) broken.

    I personally lost track of when, what will be fixed, in the forums I see a lot of "will be fixed in the next release", I have found stuf not working in pr1, working in pr2, not working in pr3 and working again in pr4 (and broken in 5 again, haha)

    Yes it is pre release, but keep in mind that we are not monkeys!! For new developments no one will ever start in extjs3 when looking at the 4 features.

    A lot of people just want a way to edit data in some sort of database in forms.
    Defining this using a model is super! no comments about that.

    but not being able to tie a model to a form........ sorry, YOU NEED TO IMPLEMENT THAT IN 4.0

    Besides that, REST communications are nice for php script kiddo's but Ext.Direct allows so much more automation and flexibility.

    doing a model.load(123,......) is in the 4.0 docs for ages and ages.

    Just that Ext.Direct does not send out the 123..... It is all over the forums (no surprice the Sencha Dev team looses track of the issues in the forum) with some other stuff.

    "Will be fixed in the next release......"..... Duh

    Although we are buying one licence at the moment (not sure if it is out yet, different dept.) I will need to find some other solution if Sencha keeps "non communicating" in terms of releases and proper documentation. API docs are fine after one knows how stuff works.

    One HUGE complaint here is that all the demo's have different approaches. there are so many ways of getting data to and from the server and they are all mixed.

    someone spend 4 DAYS trying to get a model loaded into a form, he spend hours and hours searching the forums, API docs etc.

    Sencha, next time blog about features but DO NOT do pre-releases and release a proper Beta.
    Or release just the parts that work, too many things are broken.

    Personally I am starting to HATE Extjs for this. Putting stuff up with Touch is one idea but there is no Direct in Touch (have not looked into 1.1) I managed to "hack" the Direct functionality into touch 1.0 just to find out that Ext.copyTo was not in Touch etc, etc.

    If you want to drive a Ferrari in the desert, you need to build a proper road first! Please, please, please stop focussing on VISUAL stuff "the Ferrari" and make sure the Data and transport "the road" are properly done and consistent over extjs and touch and nicely documented. then you can build nice grids, forms etc.

    ExtJs is an absolute nightmare for an Architect/project manager. I am holding back ExtJs for 3 years now in terms of using it for production. There is no way of telling how long a developer will need to implement something in Extjs since there is all ways a last "snag". I do not know how to explain in the board meetings that there is no way of knowing when 50+ developers should have something "working". Extjs is the first "development suite" I need to play with myself because nobody here can tell me what decisions to make and how to use it in a way that suits us and would work for a reasonable long time without us being a Sencha "slave" in terms of not being able to get new functionality in....

    Stop behaving like a startup, please, please, please, please (or try and go working iso900X)

    Jash


    (I guess the answer will be: Will be fixed in the next version, surprise me)

Similar Threads

  1. Replies: 0
    Last Post: 21 Mar 2011, 1:00 PM
  2. Replies: 0
    Last Post: 20 Mar 2011, 2:43 AM
  3. Replies: 1
    Last Post: 17 Mar 2011, 4:21 PM
  4. Replies: 1
    Last Post: 4 Aug 2009, 4:58 PM

Thread Participants: 6