Closed GoogleCodeExporter closed 9 years ago
I was having the same problem. Took me a while to track down but it was due to
conflicting plugins. The culprit was jquery.validate.js
http://docs.jquery.com/Plugins/Validation
It's 2am, so I don't have it in me to track down the problem :)
Original comment by jmat...@gmail.com
on 29 Apr 2009 at 9:03
I couldn't go to sleep knowing there was a JavaScript conflict.
The problem was that the validation plugin defined $.format. I renamed it
$.validation_format and everyone was happy.
Original comment by jmat...@gmail.com
on 29 Apr 2009 at 9:06
Thanks a lot for finding this conflict, I've added a warning the wiki page of
the format.
I'm not sure how I will address this yet.. I might change the method name.
Original comment by hainea...@gmail.com
on 29 Apr 2009 at 6:31
[deleted comment]
I renamed $.format to $.validation_format in the jquery.validate.min.js file
and I'm
getting the proper value in the timepickr drop down, but now I'm getting
NaN:NaN in
the input. Any suggestions?
Original comment by timbor...@gmail.com
on 30 Apr 2009 at 6:56
@timborden:
If you remove the jquery.validate plugin completely does it still behave like
this ?
Original comment by hainea...@gmail.com
on 30 Apr 2009 at 8:11
@haineault:
No, it appears to behave as expected.
(Note: I was using jquery.timepickr successfully prior to using jquery.validate)
Original comment by timbor...@gmail.com
on 30 Apr 2009 at 9:13
Discovered the error. It's unrelated to the above issue, but I thought I'd
share. I
was using the class name "date" for the datepicker and 2 timepickr text inputs
in the
form. As result, the validation plugin was executing prior to form submission,
resulting in the NaN:NaN. I changed my class name, and it now works as
expected.
Original comment by timbor...@gmail.com
on 1 May 2009 at 12:47
@timborden
The problem occurs because the validation plugin author use a method called
$.format
which conflicts with a method present in jQuery.utils (see string format). Both
method are very similar, except than mine is a near complete implementation of
Python
3000 Advanced String Formatting and the one he's using is basically a
search/replace
method for strings.
So it's somewhat normal to see unexpected behavior when the validation plugin
use my
version of $.format and vice-versa.
I've already contacted the author about this issue and he agreed to scope or
rename
his method. So you can expect this to be fixed in the next releases of the
$.validation plugin.
Original comment by hainea...@gmail.com
on 3 Jun 2009 at 7:38
Issue 27 has been merged into this issue.
Original comment by hainea...@gmail.com
on 3 Jun 2009 at 7:42
Validate 1.5.3 will deprecate $.format, and 1.6 remove it, in favor of
$.validator.format. When you load the validation plugin and don't use any
third-party
custom methods, just restore $.format to its previous value after the plugin was
loaded and you should be good to go.
I hope to release 1.5.3 in a few days, check bassistance.de for updates.
Original comment by joern.za...@gmail.com
on 9 Jun 2009 at 3:15
I'm still having an issue with this and none of the suggestions helped. Here
is my
scenario:
JS included on the page (in order): jquery 1.3.2, jquery-ui-1.7.1.custom,
validate,
treeview, tooltip, timepickr
Creating timepickr: $('#myfield').timepickr({ convention: 12 })
Activating validation: $('#myform').validate();
Symptoms of problem:
0. both IE and firefox
1. if #myfield does not have class="required" on it, it works perfectly. The
timepickr plugin displays properly and allows me to pick the time.
2. if #myfield has class="required" on it and is filled in BEFORE submitting the
form, everything works fine.
3. if #myfield has class="required" and it is NOT filled in, it validates fine
but
when going back to fill in the text box, I get "NaN:NaN " in the text box (I
used
quotation marks to show the space).
@joern: I tried the latest from bassistance's svn and it doesn't seem to help.
Do I
need to do anything with the $.format, like delete it? If so, how do I do that?
@timborden: I am only using required, not date, so I *do not* have
class="required date"
Anyone have any idea or fix?
Original comment by dan.andr...@gmail.com
on 10 Jun 2009 at 4:18
bump - I've installed Joern's new 1.5.3 release and I still have the problem I
described above. Basically once the field is marked invalid, trying to pick any
value from the timepickr results in NaN:NaN showing up in the text box. I've
attached a screenshot of the field before and after validation so you can see
what I
mean.
Original comment by dan.andr...@gmail.com
on 15 Jun 2009 at 4:09
Attachments:
Ok, since nobody wanted to help me ;) I figured it out.
@haineault:
The problem was contained in timepickr, sort of. Here's how the getValue looks
(this
gets called to get the hours, minutes, etc. before updating the text box):
getValue: function(type) {
return $('.ui-timepickr.'+ type +'.hover', this.element.next()).text();
}
notice the this.element.next() call. If you have validation enabled on the same
field, the next element will be the <label class="error">message</label> one.
So,
making getValue look like this fixes the problem:
getValue: function(type) {
var next = $(this.element).parent().children('span.ui-helper-reset');
return $('.ui-timepickr.' + type + '.hover', next).text();
}
Not sure it's the best way, but it works. Attached is the fixed timepickr.min.
Original comment by dan.andr...@gmail.com
on 18 Jun 2009 at 4:14
Attachments:
@dan.andreescu
I've done a complete rewrite of the plugin and I'm now using more "sane"
methods to
get/set the time. Could you verify against the trunk if you still see the
problem
you're talking about please.
If so please fill in a new bug report, I'm trying to get rid of all the old
pre-refactor bug reports since most of them aren't relevant anymore..
I'm officially closing this issue now.
Thanks
Original comment by hainea...@gmail.com
on 6 Aug 2009 at 6:02
The conflict with bassistance validation plugin can be resolved just commenting
this line in the validation plugin:
"$.format = $.validator.format;"
Original comment by endel.dreyer
on 1 Aug 2010 at 11:31
Original issue reported on code.google.com by
ja...@lentink.net
on 23 Mar 2009 at 10:43