-
23 Jun 2009 7:45 PM #11
Yes, with disableValidation set, it will only ever fire if you explicitly call validate() with some kind of "force" parameter.
Evan Trimboli
Sencha Developer
Twitter - @evantrimboli
Don't be afraid of the source code!
-
24 Jun 2009 4:03 AM #12
May do it ...
May do it ...
That may do it. I still don't see a valid reason why with all field settings turned off the system validates on setValue only. Think about it .... you have a field, it does not validate when you update the value immediate, nor when you leave the field, but when you set the value using code - it runs validation and shows the error. Why?
Could you please tell me the use case / schenario you are attempting to keep from breaking by having the system validate when you setValue in a TextField, but not when you blur or keyup?
This is very inconsistant bahavior. Sure seems "buggy" if it is not an outright bug to have a setting that turns something 1/2 off ... usage of the system should be more cut and dry then that .. how will you document that? The documentation does not clearly state that with all validation turned off .. when you set a field using setValuie it runs validation anyway.
If you have a valid use case, I would like to know what that is .. maybe I'll learn a new trick.
Thanks for your replies,Joseph Francis,
CoreLan / Meeting Consultants
-
24 Jun 2009 4:53 AM #13
This is why we're making the changes. As the name implies validationEvent is for hooking up events to validation. Setting this to false doesn't necessarily mean you want to disable all validation, which is the premise behind adding a new parameter to forcibly disable any automatic calling of validate.
Evan Trimboli
Sencha Developer
Twitter - @evantrimboli
Don't be afraid of the source code!
-
24 Jun 2009 5:32 AM #14
This change will effect existing functionality?
This change will effect existing functionality?
If disableValidation is set to false and validationEvent to false .. then I set a value using setValue .. will it still validate and show a red box?
Joseph Francis,
CoreLan / Meeting Consultants
-
24 Jun 2009 5:37 AM #15
Yes, once again, validationEvent merely indicates a set of events to fire validation on. If this is empty, then it means don't validate on any events, but it will still be called inside setValue unless disableValidation is set to true.
Evan Trimboli
Sencha Developer
Twitter - @evantrimboli
Don't be afraid of the source code!
-
24 Jun 2009 6:17 AM #16
so ...
so ...
So the system will still continue to not validate on blur and not on keyup, but when you set the value - it shows the red box for invalid. If you call that working as designed I'll simply override myself when the release hits.
Thanks for the other change and doing this volly to be sure I understand.
RegardsJoseph Francis,
CoreLan / Meeting Consultants
-
24 Jun 2009 6:21 AM #17
Perhaps I'm not being clear. We are adding a new configuration option to disable ALL valdiation unless you explicitly call validate. validationEvent will behave as it currently does, to hook up events to validation. If the new configuration to disable validation is set, it will ignore any validationEvent.
Evan Trimboli
Sencha Developer
Twitter - @evantrimboli
Don't be afraid of the source code!
-
24 Jun 2009 6:40 AM #18
Great ...
Great ...
Thanks for all your work in this area

It will make a huge difference in my ability to make the 3.x jump
cheers
Joseph Francis,
CoreLan / Meeting Consultants
-
25 Aug 2011 8:34 AM #19
You found a bug! We've classified it as
a bug in our system.
We encourage you to continue the discussion and to find an acceptable workaround while we work on a permanent fix.


Reply With Quote