PDA

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



wizkid
10 Mar 2011, 5:08 PM
Strait from the documentation:

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

Now consider this snippet


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)



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! =D>

estesbubba
10 Mar 2011, 6:03 PM
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.

wizkid
10 Mar 2011, 6:17 PM
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!

mitchellsimoens
11 Mar 2011, 6:23 AM
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 :D 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.

estesbubba
11 Mar 2011, 6:40 AM
Now I'm at work, here is the simple method I wrote.



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

Ext.each(recErrors.items, function(item) {
errors.push({
id: item.field,
msg: item.message
});
});

return errors;
}

wizkid
11 Mar 2011, 8:06 AM
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 :D 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 :D

wizkid
16 Mar 2011, 3:22 PM
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.

wizkid
23 Mar 2011, 2:56 PM
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.

jjohnston
25 Mar 2011, 11:15 AM
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.

jash
28 Mar 2011, 6:02 AM
+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)

jamesgpearce
28 Mar 2011, 6:57 AM
Jash, thank you for your post & there's no doubt we sense your frustration.

Certainly we understand that a framework like ExtJS will be used in complex, high-profile deployments - and as we start to enter the beta process, I am confident that you will see the quality of the framework converge upon that expectation.

In the meantime, thank you for your patience, and in raising particular issues. If you have any further questions or feedback, don't hesitate to let us know.

adept07
5 Mar 2014, 6:41 PM
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.

Hi jjohnston

Based on your previous comments, just wanted to know if the automatic binding of data models and stores to forms is available yet.
Though I found some solutions in the forums, but really wanted to check if this feature is supported by the framework yet, if not when would this be available? Right now I am using 4.2.2

Your reply would be highly appreciated.